The BPMN (Business Process Model and Notation) specification allows the use of various constructs that are correct, but create a lot of confusion. I call such a way of modeling "Messy BPMN." See what I mean here.
In BPMN, "Uncontrolled Flow" refers to a sequence of activities that occur without strict predefined rules or conditions. In this context, "uncontrolled" means that the flow of activities isn't governed by explicit decision points or gateways.
This notation follows the BPMN specification and has a specific meaning. What can we say about activity D? When will it be executed?
If more than one sequence flow enters or comes out of an activity and we don't use gates, the BPMN standard says that there are still gateways there, just implicit ones. In other words, an implicit gateway is not shown on a diagram, but it still governs the flow of the process.
Let's present this example again, this time explicitly showing the implicit gateways called for by the BPMN notation:
In the flow shown above, after activity A finishes, 2 tokens are available, one of which can execute B and the other C. And now the most interesting part begins. Whichever of these two activities (B or C) finishes first will pass on its token, and activity D will run for the first time. When the second of the two activities (B or C) ends, D will be launched once again.
This scenario is syntactically correct, but it is usually not what we have in mind. Usually we want to wait for both B and C to finish before moving on to D.
Our takeaway: When we don’t use explicit gateways, it's easy to make a logical error and create a diagram that means something other than what we intended.
Let's see another example:
Again, we can see that this diagram contains implicit gateways. Here’s what this diagram looks like if we show the implicit gateways called for by the BPMN standard:
Activities A and B can be run independently, so we have 2 tokens from the beginning. Activities C, D and E will execute twice. If you don't include explicit gateways in our diagrams (using so-called “uncontrolled flow”), it is easier for us to miss something, or for the person reading the diagrams to misinterpret the process logic.
The omission of start and end events doesn't make things any easier either.
A conditional flow (represented by a mini-diamond shape) in BPMN can be useful when a process has decision points that require different actions based on specific conditions. Conditional flow uses a small gateway icon that distinguishes it from regular sequence flow.
This is a correct example of a BPMN diagram, in which conditional flows were used instead of regular gateways. This example can again be translated into one that uses explicit gateways.
But the question arises - what type of gates should be used? Should we create the diagram shown below on the left (with an exclusive gateway), or on the right (with an inclusive gateway)?
The answer is - it depends. If both conditions are exclusive, we would use the exclusive gateway.
In general we should use an inclusive split in such a scenario, so the second diagram is correct.
We can make this example even more complicated by adding a default flow and a regular sequence flow.
If we show the same example using explicit gateways, it looks like this:
It is not easy at first glance to understand the correct logic of a process described by conditional flows without explicitly using gateways.
Both “uncontrolled flow” and “conditional flow” conform to the BPMN specification and can be used. However, the use of uncontrolled flow requires a very good knowledge of the BPMN standard, both for the person creating the diagram, and for the person reading it. It can sometimes lead to wrong conclusions.
The easiest way to simplify diagrams is to use explicit gateways instead of uncontrolled flow. Using explicit gateways will allow you to better represent what the process should do and catch possible modeling errors. It will also help the reader of the diagrams understand how the process will work.
Take the Messy BPMN Quiz to test your knowledge!