Mysteries of the BPMN Inclusive Gateway

In the BPMN specification there are three basic gateways types: exclusive (also known as decision gateway), parallel and inclusive. The first two are simple to understand, but the last one can be a bit trickier.

Definition

The Inclusive Gateway is a mix of the exclusive and parallel gateways:

• Exclusive - because it is used to make choices, and you can have more than one choice that's right.
• Parallel - because when there's more than one choice, there are multiple paths that can be taken. It can also be used to bring things back together under specific circumstances.

Example 1

Splitting

The splitting behavior of the inclusive gateway is clear enough: 

• If one condition is true, it doesn't mean we ignore the others. We'll follow all the true paths. 
• Each path is like its own story and they can all happen, from none to all of them. But it's a good idea to make sure at least one path is taken.

Here are the possible scenarios in the case above:

• If the amount is greater than 0 and less than or equal to 2000:

• If the amount is greater than 0 and less than or equal to 10000:

• If the amount is greater than 10000:

Default flow

Be careful when using a default flow outgoing from an inclusive gateway. 

Example 2

Using a default flow can completely change the situation because the "process order" won't happen at the same time as the other paths. 

Here are the possible scenarios in the case above:

• If the amount is greater than 2000 and less than or equal to 10000:

• If the amount is greater than 10000:

• In any other case:

Joining

It is not simple to describe how an inclusive gateway brings everything back together. How does a process know that it has to bring certain flows back together? Let's modify this example slightly by adding an exclusive gateway and adding / modifying tasks:

Example 3

1. What will happen if the amount is greater than 10000 and the discount won’t be granted? Are we stuck or not? Does the second inclusive gateway expect 2 tokens, or does it expect 3 tokens?
2. How can the synchronization mechanism be explained? 

The official BPMN rules say: "A control flow token arriving at an Inclusive Gateway MAY be synchronized with some other tokens that arrive later at this Gateway”.

This means the process looks at all the previous paths and waits for a token for each one. The process always knows which paths are happening or can happen at a certain time. When we're at the inclusive gateway, we know what already happened or what might happen next.

Even if a previous decision is negative, the joining gate must wait until the decision is completed. 

The inclusive gateway is handy when we want to easily describe situations where more than one condition can be met. Try to describe the diagram in Example 3 without using inclusive gateways, and you will see how complicated it gets.

Unfortunately, the mechanisms for bringing flows back together through this gateway aren't entirely clear. We should use it carefully and not make our diagrams too complicated.

Boundary non-interrupting event

One more example of when the inclusive gateway is useful - for merging flows after a non-interrupting boundary event - is shown in the following example:

Example 4

The only way we can bring together the two flows outgoing from "verify customer” and “inform about the delay” is to use an inclusive gateway.

Summary

The BPMN inclusive gateway is a tool used in process modeling. It helps manage different paths a process can take. Unlike an exclusive gateway, it allows for multiple paths to be followed at once. This gateway makes it easier to bring things back together in a flexible way.

Using a default path from the inclusive gateway can change the flow of the process significantly. It's important to be cautious when implementing this element to ensure the process unfolds as intended.

The BPMN standard does not impose any restriction that only flows from the previous gateway can be combined. There may be multiple tokens flowing into a gateway from more than one gateway earlier in the flow. When this happens, the gateway always knows to wait for all possible flows. When building your model, you can ignore the implementation of the processes and just focus on the business aspect. When the process needs to merge flows together, it will automatically monitor all possible flows and track all active tokens as they move into the merge. We only need to be careful to check all possible flows leading into the merge, and remember that the process will first wait for all of the ones that are active, and then combine the incoming flows.

Inclusive Gateway Quiz (Level 2, Lesson 2)

Take the Inclusive Gateway Quiz to test your knowledge!