Inclusive Gateway to parallelize the workflow
In many business processes, parallelism is essential. It allows tasks to be assigned that can be carried out simultaneously rather than sequentially. This approach is especially useful when the tasks are independent of one another. By introducing parallelism into the workflow, it becomes easier for different users to work on multiple tasks at the same time, leading to significant time savings.
To implement parallelism in the workflow, an inclusive gateway is used in the process design.
To insert it, simply drag the gateway onto the diagram and connect it to the other elements.
The operation of the gateway is based on the incoming or outgoing flows. It can behave as a “forking” gateway when used to split the flow into multiple paths, or as a “joining” gateway when used to join different paths into a single one.
This behavior represents a split in the flow toward two or more different routes.
Optionally, the outgoing flows can have conditions that will be checked at execution time. This means that in the forking behavior, the conditions on all outgoing arrows are evaluated, and for those that evaluate to true, the flows continue in parallel, creating a simultaneous execution (or token) for each path.
In the absence of conditions, all tasks will be executed in parallel.
Example:
In this example, parallelism is activated after the purchase order is entered. Since there are no conditions, two tokens will be created and both tasks will be assigned to the corresponding users: those who must complete the Receive Payment task and those who must complete the Ship order task.
You can also set conditions to determine which tasks should be executed:
In this case multiple scenarios can happen, depending on which conditions are met: both tasks will be executed in parallel or only one of them.
For example, if the customer has already paid the product, only the task Ship order will be assigned.
The conditions are set by clicking on the outgoing transitions (arrows) of the inclusive gateway. At least one condition must always be met.
The inclusive gateway is also used to join different paths and continue the process as a single flow. In the joining behavior, all executions arriving at the gateway will wait until all active tasks are completed before proceeding to the next stage.
Example:
When the Receive Payment and Ship order tasks are completed, the second inclusive gateway joins the two executions, and since there is only one outgoing flow, no parallel execution paths are created and only the Archive Order task will be active.
The join will trigger when:
It receives a number of tokens greater than or equal to the number of incoming transitions. The tokens do not necessarily need to reach the gateway through different transitions.
It receives a number of tokens smaller than the number of incoming transitions and no more tokens that can arrive at the gateway.
Note that it is not necessary for the gateway to have the same number of incoming/outgoing flows for the corresponding inclusive gateways. An inclusive gateway will simply wait until one of the conditions above is met and will create a parallel execution path for each outgoing flow, regardless of other configurations in the process diagram.
An inclusive gateway can simultaneously have both diverging and merging behavior if it has several incoming and outgoing sequence flows. In that case, the gateway will first merge all executions from the incoming transitions before splitting into multiple parallel execution paths for the outgoing arrows whose condition is true.
Avoid generating cycles when using inclusive gateways. Otherwise, you could create a flow that never ends.
Do not configure flows like this:
In this case, the first step was to parallelize the Receive Payment and Ship order tasks. When both tasks are completed, the inclusive gateway receives two tokens (one for each incoming arrow) and directs the flow toward Archive Order. However, since the flow was configured to create a New order at the same time the path continues toward Archive Order, this will create a new purchase order, which may be undesirable.
Another possible issue is the following:
Exclusive gateways, unlike inclusive gateways, are not used to join paths. In this case, when the Receive Payment task is completed, the flow will automatically proceed to Archive Order, and the same will happen when the Ship order task is completed. The result will be that two purchase orders are archived for the same process instance, which is not advisable.
You also should not attempt to replicate this situation by joining the paths in the Archive Order task, as shown in the following image:
This case would generate the same result as the previous one. Remember that the only way to merge multiple paths is through an inclusive gateway.
If timers are combined with an inclusive gateway (see image), special care must be taken.
In this case, if the Receive Payment task is completed before the timer, the flow will continue. This is because inclusive gates do not take into account flows from timers associated with user tasks.
The solution is to include an explicit arrow in addition to the one coming from the timer, so that the joining gateway recognizes that there is an explicit path and then waits for the Ship order task.
If it is a task that should only be completed by a timer, then simply remove the decision on that task so that no user can complete it proactively.
To implement parallelism in the workflow, an inclusive gateway is used in the process design.
To insert it, simply drag the gateway onto the diagram and connect it to the other elements.
The operation of the gateway is based on the incoming or outgoing flows. It can behave as a “forking” gateway when used to split the flow into multiple paths, or as a “joining” gateway when used to join different paths into a single one.
Forking
This behavior represents a split in the flow toward two or more different routes.
Optionally, the outgoing flows can have conditions that will be checked at execution time. This means that in the forking behavior, the conditions on all outgoing arrows are evaluated, and for those that evaluate to true, the flows continue in parallel, creating a simultaneous execution (or token) for each path.
In the absence of conditions, all tasks will be executed in parallel.
Example:
In this example, parallelism is activated after the purchase order is entered. Since there are no conditions, two tokens will be created and both tasks will be assigned to the corresponding users: those who must complete the Receive Payment task and those who must complete the Ship order task.
You can also set conditions to determine which tasks should be executed:
In this case multiple scenarios can happen, depending on which conditions are met: both tasks will be executed in parallel or only one of them.
For example, if the customer has already paid the product, only the task Ship order will be assigned.
The conditions are set by clicking on the outgoing transitions (arrows) of the inclusive gateway. At least one condition must always be met.
Joining
The inclusive gateway is also used to join different paths and continue the process as a single flow. In the joining behavior, all executions arriving at the gateway will wait until all active tasks are completed before proceeding to the next stage.
Example:
When the Receive Payment and Ship order tasks are completed, the second inclusive gateway joins the two executions, and since there is only one outgoing flow, no parallel execution paths are created and only the Archive Order task will be active.
When is the join triggered?
The join will trigger when:
It receives a number of tokens greater than or equal to the number of incoming transitions. The tokens do not necessarily need to reach the gateway through different transitions.
It receives a number of tokens smaller than the number of incoming transitions and no more tokens that can arrive at the gateway.
Note that it is not necessary for the gateway to have the same number of incoming/outgoing flows for the corresponding inclusive gateways. An inclusive gateway will simply wait until one of the conditions above is met and will create a parallel execution path for each outgoing flow, regardless of other configurations in the process diagram.
An inclusive gateway can simultaneously have both diverging and merging behavior if it has several incoming and outgoing sequence flows. In that case, the gateway will first merge all executions from the incoming transitions before splitting into multiple parallel execution paths for the outgoing arrows whose condition is true.
Avoid these issues
Avoid generating cycles when using inclusive gateways. Otherwise, you could create a flow that never ends.
Do not configure flows like this:
In this case, the first step was to parallelize the Receive Payment and Ship order tasks. When both tasks are completed, the inclusive gateway receives two tokens (one for each incoming arrow) and directs the flow toward Archive Order. However, since the flow was configured to create a New order at the same time the path continues toward Archive Order, this will create a new purchase order, which may be undesirable.
Another possible issue is the following:
Exclusive gateways, unlike inclusive gateways, are not used to join paths. In this case, when the Receive Payment task is completed, the flow will automatically proceed to Archive Order, and the same will happen when the Ship order task is completed. The result will be that two purchase orders are archived for the same process instance, which is not advisable.
You also should not attempt to replicate this situation by joining the paths in the Archive Order task, as shown in the following image:
This case would generate the same result as the previous one. Remember that the only way to merge multiple paths is through an inclusive gateway.
Parallelism and Timers
If timers are combined with an inclusive gateway (see image), special care must be taken.
In this case, if the Receive Payment task is completed before the timer, the flow will continue. This is because inclusive gates do not take into account flows from timers associated with user tasks.
The solution is to include an explicit arrow in addition to the one coming from the timer, so that the joining gateway recognizes that there is an explicit path and then waits for the Ship order task.
If it is a task that should only be completed by a timer, then simply remove the decision on that task so that no user can complete it proactively.
Updated on: 17/02/2025
Thank you!