Complex gateways in BPMN can seem difficult at first. I felt the same when I started modeling advanced process logic. However, once I understood them, I saw how useful they are for special routing situations. In this article, I explain complex gateways in BPMN in a clear way, show when they make sense, and help you understand how to model more demanding process behavior with confidence.
To understand the gateway, I think in terms of tokens.
Each active process path carries a token. When a token reaches an incoming sequence flow of the complex gateway, the gateway evaluates its activation condition. If the condition is not yet true, the gateway waits.
Once the activation condition becomes true, the gateway activates. It consumes the relevant incoming tokens and evaluates its outgoing sequence flows. The conditions on those flows then determine where new tokens continue. (OMG)
For example, suppose I have three parallel checks:
- Check A finishes.
- Check B finishes.
- Check C finishes.
If my activation rule requires two completed checks, the first result alone does not activate the gateway. However, the second result satisfies the condition. The gateway can then continue the process.
A complex gateway does not simply wait for every incoming path. Instead, I define the combination of incoming tokens that activates it.
That distinction separates it from a parallel gateway.
Example: Continue After Two of Three Responses
Suppose I want opinions from three people before I choose a pizza restaurant. I send all three requests at the same time. However, I do not want to wait for every person.
Two responses give me enough information.
I can therefore model three parallel activities:
- Ask Friend A
- Ask Friend B
- Ask Friend C
All three paths lead into a complex gateway. I then define an activation condition that requires two incoming results.
As soon as the required threshold is reached, the gateway can activate and the process can continue to “Decide on Pizza.”
However, there is an important detail. The third response does not simply disappear. BPMN defines additional reset behavior for complex gateways. Therefore, I must consider what happens when the remaining token arrives later.
The Reset Behavior Is Important
This is the part that many simplified explanations leave out.
A BPMN complex gateway has internal state. Initially, it waits for its activation condition. After activation, it changes state and waits for a reset. BPMN calls these states “waiting for start” and “waiting for reset.” (OMG)
Suppose my rule says “two of three.” Friend A and Friend B reply first. The gateway activates and the process continues.
Later, Friend C replies.
The BPMN specification explicitly accounts for such remaining tokens. They participate in the gateway’s reset behavior, and the gateway can potentially produce another outgoing token depending on its outgoing conditions. (OMG)
Therefore, a “two out of three” complex gateway does not automatically mean “continue once and permanently ignore every later result.”
If I need exactly that behavior, I must model it deliberately. For example, I may need additional process logic that cancels remaining work, records that the decision already occurred, or prevents repeated downstream processing.
This detail matters especially when I create executable BPMN models.
Example: Continue After the First Result
The same issue becomes even clearer with a one-out-of-two rule.
Suppose I start two activities at the same time:
- Check Supplier
- Search Alternatives
I want to place the order as soon as one activity produces a useful result.
At first sight, a complex gateway with a one-of-two activation condition appears ideal. The first arriving token satisfies the condition immediately.
However, I would not describe this diagram simply as “the first result wins and the second result is ignored.”
The remaining activity can still complete. Consequently, another token can reach the gateway. Because the complex gateway has reset semantics, I must define what that later arrival should do.
If I actually want a race in which the first result wins and the other alternative stops, I first check whether another BPMN pattern expresses that behavior more clearly.
I use a complex gateway only when I genuinely need complex synchronization, not merely because several process paths meet at one point.
Complex Gateway vs. Other BPMN Gateways
Before I add a complex gateway, I compare the requirement with the standard gateway types.
| Requirement | Gateway I normally use |
|---|---|
| Choose exactly one path based on data | Exclusive gateway |
| Start or synchronize all required paths | Parallel gateway |
| Select several paths based on conditions | Inclusive gateway |
| Continue according to the first occurring event | Event-based gateway |
| Synchronize according to a custom combination such as two of three | Complex gateway |
This comparison usually prevents unnecessary complexity.
For example, if every parallel branch must finish, I use a parallel gateway. If any combination of conditionally activated branches must synchronize, I examine the inclusive gateway. If I wait for one of several events, I use an event-based gateway.
Only when these standard semantics do not match the requirement do I consider a complex gateway.
When I Use a Complex Gateway
I consider a BPMN complex gateway when three conditions apply.
First, the process contains several incoming paths that can become active concurrently.
Second, I cannot express the synchronization rule with a standard gateway.
Third, I can define the activation condition precisely.
Typical examples include approval thresholds, quorum rules, voting processes, multi-source verification, and situations where only a defined number of parallel results must become available before processing continues.
For instance, I might require three approvals from five reviewers. Waiting for all five would slow the process unnecessarily. Continuing after one approval would provide too little control. A three-of-five activation condition expresses the real business rule directly.
If I cannot explain the activation rule in one clear sentence, I usually simplify the process before I introduce a complex gateway.
When I Avoid a Complex Gateway
I avoid it when a simpler BPMN element communicates the same behavior.
That principle matters because complex gateways are uncommon. As a result, readers may need additional explanation before they understand the model.
I also avoid them when the process engine does not support their execution.
This point is especially relevant for Camunda.
Can I Use Complex Gateways in Camunda 8?
Not for normal Camunda 8 execution.
Camunda 8 currently documents support for exclusive, parallel, event-based, and inclusive gateways. It does not list the complex gateway among its supported executable gateway elements. (docs.camunda.io)
Therefore, the statement that I can simply model a BPMN complex gateway and execute its custom synchronization logic in Camunda 8 would be misleading.
If I design an executable Camunda 8 process, I do not rely on a BPMN complex gateway.
Instead, I model the required behavior with supported BPMN constructs or move the rule into explicit process logic. The exact solution depends on the requirement. For example, I may track completed responses in process data and evaluate the threshold with supported gateway and task patterns.
This approach may require more elements. However, it also makes the executable behavior explicit.
Is a Complex Gateway a Good BPMN Practice?
Yes, but only for the problem it was designed to solve.
The complex gateway is part of BPMN because some synchronization rules genuinely exceed the semantics of parallel and inclusive gateways. The official BPMN specification explicitly supports threshold-style conditions such as three incoming tokens out of five. (OMG)
Nevertheless, I do not use complexity as a shortcut.
I first ask:
“Can I express this rule correctly with an exclusive, parallel, inclusive, or event-based gateway?”
If the answer is yes, I choose that gateway.
If the answer is no, and I need a custom synchronization condition across incoming paths, the complex gateway becomes relevant.
Final Thoughts
The BPMN complex gateway solves a narrow but important modeling problem. It lets me define custom synchronization conditions such as two out of three or three out of five incoming paths.
However, activation is only part of its behavior. I also consider later incoming tokens and the gateway’s reset semantics. Otherwise, a diagram that looks simple can behave differently from what I intended.
I use a complex gateway when the business rule itself requires complex synchronization, not when I simply need a convenient way to merge several lines.
That distinction keeps my BPMN models precise. It also makes them easier to explain, review, and implement.
What’s Next?
If I want to model process decisions more clearly, the next step is to explore Exclusive Gateways in BPMN 2.0: Clear and Simple. In that article, I show how exclusive gateways guide a process into exactly one path based on a condition or decision. As a result, I can represent business rules more precisely, avoid confusion in my diagrams, and create BPMN models that are easier to understand and discuss.
Discover the Full Value of Requirements Modeling
If I want to understand requirements in a clearer and more structured way, I need more than text alone. I need models that show how ideas, processes, and system structures connect. In the main article on Requirements Modeling, I explore essential Modeling Concepts, Process Modeling with BPMN, and the structural perspective of UML. Together, these topics help me analyze requirements more effectively, communicate them more clearly, and build a stronger foundation for successful system design.
With these insights, I can also take the next step into the main article on Processes. There, I explore Process Management, BPMN, and Camunda as a practical tool for BPMN modeling. Therefore, I can connect requirements with real workflows, process logic, and improvement opportunities. Click through to learn how Processes help me structure work, improve collaboration, and turn process knowledge into practical business value.
Credits: The diagrams were created with Camunda.
| Read more about Business Process Modeling and Notation (BPMN) |
|---|
| Exclusive Gateways in BPMN 2.0: Clear and Simple Parallel Gateways in BPMN 2.0: Understanding and Using Them Effectively Event-Based Gateways in BPMN 2.0: A Practical Guide Complex Gateways in BPMN 2.0: A Simple Guide |