Agree, I used to many terms that could make the solution bit fuzzy.... let me put it here:
- node is a definition of a particular logic in the process (bpmn)
- node instance is a runtime element of process instance build based on node
- task is a special representation of a node
- task instance is an instance created based on task and maintained by Task Server that has its life cycle as defined in WS-HumanTask spec
- actor id is a potential owner defined in bpmn - as potential owner is kept as ActorId in work item properties
- group id that is rather self explanatory
With that in mind, when Task A is entered it creates task instance A (based on Task A), when it is completed engine creates task instance B (based on task B), assuming that approver rejects the task instance A outcome, it will create task instance C (based on Task A), meaning worker that completed task instance A will work on brand new task instance.
What I suggested was that instead of going back to Task A (and create task instance based on it for rework) add new Task C that will be dedicated to rework. In general it does not change much in the concept, it simplifies user assignment as it differs based on the process state. Task A and Task B assign users based on groups and task C assigns individual who completed Task A (instances of those tasks).
Regarding assignments, yes, you can use process variables to assign users, #{variable}, take a look at the example from my previous post where group id is assigned based on process variable. So that would mean following:
- Task A assigns users based on group with #{worker-group} process variable
- Task B assigns users based on group with #{approvers} process variable
- Task C assigns user based on potential owner with process variable #{TaskA-actualOwner}
Does that sound suitable for your case?
Hope this time I cleared some things ....
Cheers