Sometimes a workflow will proceed from Task 1, 2 to 3... and then you want to go back to task 1. This is a loop structure. "Graphical Authoring" is the reason why BPM tools can allow loop structures in workflow definitions. One thing you need to be careful of, however, is adding too many loops; the workflow itself might not work properly.
<Tasks>
1. Task, 2. Task, 3. Task, 4. Task, 5. Task
[BPMN Sample <Loop>: "4. Task" screen]
<Process Data Items>
- Title
- Text A (string)
- Loop? (Select: Yes/No)
The above workflow operates properly: once the first task is completed, tasks 2 and 3 start concurrently. Tasks 3 and 4 keep looping back as long as the users checks "Yes" in the execution screen. And finally, once tasks 3, 4 and 2 are completed, task 5 starts.
On the other hand, the below workflow does NOT operate properly (It does not work as a workflow).
Let's try to explain this... in this workflow, there is the possibility that the divided flow returns to the same split point without merging again. In other words, the split may be conducted indefinitely, so BPMS (workflow engines) cannot handle the information. This kind of workflow rarely comes up in daily tasks, but it might be a good idea to remember NOT to try looping over long flows that are processed concurrently.
By the way, it would work if the loop starts AFTER the two flows are merged.
Past BPMN Lecture articles
- Split Conditions are a Basic Concept in BPMN
- BPMN Splits for flexible flow conditions
- Automatically Sending Template Emails in the Middle of a Workflow
- How to Design Primary Workflows With Many Baby Workflows