Task recall functionality

Question

Hi All, 
 
 We have a headless pattern: The task is initiated by User A(who belongs to Group A) and submitted to User B /Group B for approval, as per requirement User A who was initiator can recall the task and update the data if required and submit once again to User B for approval. So when the task is in User B&rsquo;s Bucket, along with User B ,User A can also take action (Recall to Edit) we at this point plan to give Task Assignment to both users (A & B) for it. At this point if User A acts on the Task ,then the Task must be removed from User B's bucket and vice-versa. 
 
 Has anyone implemented such solution or have once succeeded for such requirement? 
 
 Thanks in advance.

Chris · Answer

Also not sure about the headless verbiage but with a simple process, A to B, it sounds like this can be done with an Edit Related Action. If A edits, you aren't really removing the task from B as it will flow right back to them for approval, the task can stay with them with the updated data. If B has already approved, the Related Action would not be available. You can also check on the edit form to disable/show a message in the situation that B approves while A has already accessed but not yet submitted the edit. 
 For more complex recall scenarios, I typically give them a Recall Related Action which utilizes exceptions on all downstream tasks to end while starting the Submit task, which the user can then access from their Tasks List. Or, the edit can be done directly in the Related Action, then makes a call to the process which restarts the correct path(s). I typically have a rule node or a receive message event as a side path off the start event, that waits to be told to do it's processing. The Recall/Edit function calls this side path either with OOTB process messaging, the "Start All Nodes" service of the Process Management Services plugin, or by setting a process variable (Rule node scenario) in the main process with the Get and Set External Process Variables plugin. 
 In the side path, I also utilize a!queryEntity() to update the CDTs based on data that was just persisted to the DB from the Edit/Recall function. So the main process will receive input from the Edit function, update it's CDTs, then kill/start tasks as necessary.

Dave Lewis · Answer

The way I saw it done is with Process to Process messaging. The process to recall sends out a message to the PI that is holding the task for B, and that process is killed. No more task, and A can proceed to make changes, then create a brand new submit to B. 
 Process to Process is very inefficient and slow, but this is still, I think, a very good use case for it. It's very rarely used, and performance isn't critical for this type of operation. 
 There may be a better way of doing it, but I haven't been tasked with implementing it, thankfully.