Mysteries of the BPMN Inclusive Gateway

Last Updated: March 13, 2026

Key Takeaways

• An Inclusive Gateway (OR Gateway) in BPMN allows one or more paths to be taken depending on conditions.
• During a split, all outgoing flows with true conditions are activated.
• During a join, the gateway waits only for tokens from the paths that were actually activated.
• Inclusive Gateways are useful when multiple optional activities may occur in parallel.
• They are more flexible than Exclusive Gateways but more complex than Parallel Gateways.
• The synchronization logic of the Inclusive Gateway is often called the OR-Join problem.

What is an Inclusive Gateway in BPMN?

An Inclusive Gateway (OR Gateway) is a BPMN gateway that activates one or more outgoing paths based on conditions, and later synchronizes only the paths that were actually activated.

Because of this behavior, the Inclusive Gateway combines characteristics of two other gateways:

• Exclusive - Only one path is taken
• Parallel - All paths are taken
• Inclusive - One or more paths may be taken

This makes the Inclusive Gateway useful for modeling optional parallel activities.

Mental Model

Think of the Inclusive Gateway as a smart Parallel Gateway.

• A Parallel Gateway always opens all paths.
• An Inclusive Gateway opens only the paths whose conditions are true.
• Later, the gateway waits only for the paths that were opened earlier.

This dynamic behavior is why Inclusive Gateways are powerful but sometimes difficult to understand.

How does an Inclusive Gateway work?

The splitting behavior of the Inclusive Gateway is usually straightforward.

When the process reaches the gateway:

1. Each outgoing condition is evaluated.
2. All conditions that evaluate to true create a token.
3. The process continues along all valid paths.

This means:

• One path may be taken
• Several paths may be taken
• All paths may be taken

In practice, it is good modeling practice to ensure that at least one path will always be activated.

Example 1

How to read this example

This diagram shows a process where the order amount determines which approval paths are activated.

Possible scenarios include:

• Amount greater than 0 and less than or equal to 2000 - only the basic processing path is executed:

• Amount greater than 0 and less than or equal to 10000 - additional approval may also be triggered:

• Amount greater than 10000 - the highest level approval path is also activated:

Because multiple conditions may be true at the same time, more than one path can run simultaneously.

Default flow

Be careful when using a default flow with an Inclusive Gateway.

Using a default flow can completely change the situation because the default branch does not execute in parallel with other branches. The default path is activated only when none of the other conditions evaluate to true.

Example 2

How to read this example

This diagram illustrates how a default flow changes gateway behavior.

Possible scenarios include:

• Amount between 2000 and 10000 - the conditional approval path is taken:

• Amount greater than 10000 - both approvals taken:

• Any other case - only the default path is executed:

Unlike other branches, the default path is not evaluated together with other conditions. Default flows can act as a safety fallback, but they also change the behavior of the gateway.

What is the OR-Join problem (Joininig)?

The most complex aspect of the Inclusive Gateway is its joining behavior, often called the OR-Join.

The key question is: How does the gateway know which tokens it should wait for? Let's modify this example slightly by adding an Exclusive Gateway and adding / modifying tasks:

Example 3

How to read this example

This diagram demonstrates a situation where not all previously activated branches need to reach the joining gateway.

Consider the following situation:

1. The process splits using an Inclusive Gateway.
2. Several paths may start depending on the conditions.
3. One of the paths contains an Exclusive Gateway that may skip certain activities.

This raises an important question:

• If the amount is greater than 10 000 but the discount is not granted, how many tokens should the final Inclusive Gateway expect?

The BPMN specification explains this behavior as follows: "A control flow token arriving at an Inclusive Gateway MAY be synchronized with some other tokens that arrive later at this Gateway”.

In practical terms, the process engine performs the following logic:

1. It remembers which branches were activated at the split.
2. It waits only for tokens from those activated branches.
3. When all active branches arrive, the process continues.

Even if a branch later terminates early, the gateway still waits for the token produced by that branch.

This dynamic synchronization is what makes Inclusive Gateways powerful but sometimes difficult to understand.

When should you use an Inclusive Gateway?

The Inclusive Gateway is particularly useful when:

• Several conditions may be true simultaneously
• Some activities are optional
• Parallel work depends on business rules

Try to model Example 3 without using an Inclusive Gateway and the diagram quickly becomes much more complex.

Because the join logic is dynamic, Inclusive Gateways should be used carefully and with clear diagrams.

When NOT to use an Inclusive Gateway?

Avoid Inclusive Gateways when:

• only one path must be chosen (use Exclusive Gateway)
• all paths must always execute (use Parallel Gateway)
• synchronization logic would become too complex

Boundary Non-Interrupting Events

Inclusive Gateways are also useful for synchronizing flows created by Non-Interrupting Boundary Events.

Example 4

How to read this example

This diagram shows a situation where two flows can run in parallel:

• The main task Verify customer
• A Boundary Event that triggers Inform about delay

To bring these flows back together later in the process, an Inclusive Gateway is used. This allows the process to synchronize only the paths that were actually triggered.

Best Practices

When modeling processes with Inclusive Gateways:

• Ensure each branch eventually reaches the join gateway
• Avoid overly complex conditions
• Make sure at least one path can always be taken
• Document complex joins with text annotations

These practices help avoid deadlocks and confusing process behavior.

Summary

The Inclusive Gateway (OR Gateway) is a flexible BPMN element used to manage situations where one or more process paths may be activated simultaneously. Unlike an Exclusive Gateway, it allows multiple paths to run in parallel. Unlike a Parallel Gateway, it activates only the paths whose conditions are true.

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.

Frequently Asked Questions (FAQ)

What is an Inclusive Gateway in BPMN?

An Inclusive Gateway is a BPMN gateway that allows one or more outgoing paths to be activated depending on conditions and later synchronizes only those paths that were activated.

What is the OR-Join problem?

The OR-Join problem refers to determining which tokens an Inclusive Gateway should wait for when merging flows. The gateway must synchronize only the branches that were activated earlier.

What is the difference between Parallel and Inclusive Gateway?

A Parallel Gateway activates all outgoing paths regardless of conditions.

An Inclusive Gateway activates only the paths whose conditions evaluate to true.

Can Inclusive Gateways cause deadlocks?

Yes. If a process model is designed incorrectly and the gateway waits for tokens that will never arrive, the process can become blocked. Proper modeling practices help avoid this situation.

When should you use an Inclusive Gateway?

Inclusive Gateways should be used when multiple optional activities may run in parallel depending on business rules.

Inclusive Gateway Quiz (Level 2, Lesson 2)

Take the Inclusive Gateway Quiz to test your knowledge!

Related BPMN Articles

• Why are Exclusive and Parallel Gateways critical in BPMN?
• What is a Complex Gateway in BPMN and why it matters?
• Do I need a merging Exclusive Gateway in BPMN?