Interfering in a running workflow using parallel paths

Pieter Rijlaarsdam, 07 September 2011

When implementing workflow, you might run in to the fact that a change in the document that triggered the workflow should influence the running workflow.

For instance, a change of the status of the original document should stop the running workflow, or maybe restart the workflow, or maybe change the processor of a workflow task. When you design the workflow, you can ‘subscribe’ to events on the original document by adding a ‘wait’ step in your workflow. This in fact will pause the workflow until the event is raised.

Example

A simple approval workflow on a sales document is supposed to change the status on header level to approved.

If the sales document is approved directly in the document itself before the workflow task is processed by the assigned agent, you would not want to bother the agent with the task anymore, so you want to delete the task from his ‘inbox’.

So, we want to ‘subscribe’ to an event like ‘approved’. If such an event is not available, add it to your BOR object as described here and raise the event in custom coding (for instance using events as described here).

Because we don’t really want the workflow to pause until the event has occurred, we create a so-called ‘fork’ in the workflow. This allows us to create parallel paths inside the workflow. One path will contain the approval flow, the other path will have the subscribe on the ‘approved’ event.

If the ‘approved‘ event will now occur, the parallel path will be activated, and we can then influence the other path, for instance by cancelling a work item or setting a work item to obsolete using a ‘process control’ step. This will then automatically kill the existing workflow task for the user and end the workflow or continue with the next steps.