Update:
..quick "google" look on the web still produces older threads, mainly saying "forget it, will not work with any list forms)..
1. After re-mapping the new fields on the SPD workflow Task Form (customized, multi-step Approval Workflow and injected with qRules 4.3 trial) I have got it working. So it does seem possible to inject a workflow task form and it works in browser. I want to also mention that the workflow in on a custom list (not library), its own list form(s) customized with Infopath (but not injected). The custom list forms use optional sections to expand the content on the form, depending on how far the multistep workflow has progressed, including relevant information gathered during each step.
- The task form was successfully published to the server, without any warnings/issues. I did however had the sandbox solution on the server enabled, because I was testing same with pure List Forms, injected with qRules (that I could not make work). Not sure whether that was what stopped the warnings. Task Forms are supposed to work of Task Lists (I believe), so they are even more restricted with fewer options (in the advanced form options section). "Compatibility" is disabled with Form type showing Workflow Form. If it works, no complaints.
- The task form opens in the browser, from the workflow and works splendidly :). Read the end for MS Outlook client opening (Infopath) experience.
- The user validation via people picker control (non-repeating) works as expected. Could not find a way to use it directly in the repeating table, but hear it is not possible (anything better, please post a comment).
- The validated user(s)/group(s), above, together with New task Description and new Due date were successfully moved to a repating table on the same task form and view. Only OOTB Infopath rules used, double eval trick for concatenating multiple users/groups from the people picker for follow up use with qRules SubmitToSharepointList (submitting to another SP List is utilized for assigning multiple Approval(execution) tasks from a repeqting table , simulating branching(sub-tasking in real-time, multiple people with unique Due dates & more). That was tested with up to 10 distinct entries into the repeating table, unique new task titles, due dates and assigned people/groups.
- Distinct new button on the task form for submitting the new tasks from this task screen to the separate SP List to initiate multiple sub-steps approval workflows(task excutions) with their own logic - tested & working, notifications etc. You can either have the button also post a third workflow state (in addition to approved/ rejected, let say "Part3") and complete this step of the original workflow.. OR you can have the button just submit the new tasks to the other list, maybe close the form without changing the workflow status... or
- Update the taskform, without closing it, with all newly assigned tasks (for the newly inserted records into the other list, subtasks list). That also works when the workflow task form is opened after being closed (use Rules on Form Load), you can have a secondary connection for that purpose, as I did. By default qRules will update the repeating table with the Ids of the inserted records, but that's it.
...What I needed is a) the subtasks to be assigned, while the original workflow is still on the same workflow step, b) the assigned people complete their respective tasks, with comments & date completed, c) get that additional infomation into the original task form, so the Approver does see the status, completion date, etc of each sub-task assigned, BEFORE Approving or Rejecting HIS own task from the original workflow. It could be used to even add new tasks, but depending on the applied custom logic it might either restart the existing subtasks workflows (on item change) or not (If all repeating table fields are non-editable disabled and workflows activated "on create", only.
Now, I did mention all this worked better than expected opening from the browser.
What I still have to figire out and any insight is appreciated (will update if/when resolved): When the Task is opened from MS Outlook, all mentioned above works the same, except:
- for some reason, a couple of non-repating controls seem disabled, binded to non-list fields, but present on the task form. Those fields are used for sub task description and subtasks' due dates. The corresponding fields in the repeating table are editable and able to submit to the separate SP List. Even the completed subtasks, submitted by same task form(same step) are updated on load with the status/completion date of those sub-tasks.
- probably for the same reason, it must be really simple as I still can not see it, the rules on the button moving the non-repating fields(new task to be added) do not seem to fire. If I just add the info to the repating table fields it seems to work (people picker validation is why I needed something outside the repating table).
..To Be Updated.
(Please forgive, if any misspellings. Needed to share the experience as I need the feedback. Handling the Task Forms with injected qRules is very important as this is where we wanted(still do) to have the business logic for approvals/subtasking).