Hi,
I am facing a design issue regarding the use of a workflow engine (jbpm in my case).
We have some flows, with tasks, fork/joins and decision nodes, But our users want to go up 'go back' up in the flows (use case: I think the previous person in the team did a mistake, I will send my project back to him).
The particularities of our case are:
- We can go back 'over' a fork, so we are simultaneously (active tasks) before the fork and in one of the branches. They do not want the other branch to be cancelled yet as those people are maybe not impacted and should continue their tasks.
- After a 'go back' when the previous user in the previous activity solved the issue he re continuous the flow, but then we go straight to the activity of the person who did the 'go back'. We do not take the fork, thus we keep two active activities.
- Off course, after a go back, the previous user can do a new go back to his predecessor.
- They also want to go back over a decision node. 'e.g. the previous person has choosen the wrong path)
The results is that we can get in 'corrupt' states. e.g. at the same time at the two sides of a decision node.
The rationale is that every team can make errors, and those long running projects should not be cancelled, users just want to go back a few teams up to correct or assess the evolution of the project, but keep the other teams going on in their work.
I suppose this requirement is not unique to our organization, but I wonder how others have solved this, or worked around?