Task recall functionality

RE: Task recall functionality

davel001150 — Mon, 28 Jun 2021 18:46:17 GMT

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.

RE: Task recall functionality

Chris — Mon, 28 Jun 2021 16:26:00 GMT

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.

RE: Task recall functionality

Stefan Helzle — Sat, 26 Jun 2021 21:18:00 GMT

What do you mean with "headless"?

If any member of the assignees group accepts the task, he is the owner and any other user can not accept the task as well. This is default behavior of Appian.