Sometimes, timing is everything in a process. Especially when I wait for multiple signals before continuing. That’s when modeling intermediate events in BPMN 2.0 becomes essential. In this article, I’ll show you how to capture multiple events correctly—without running into dead ends or lost signals.
What Multiple BPMN Intermediate Events Mean
An intermediate catch event represents something that the process waits for while it is already running. For example, I can wait for a message, signal, timer, condition, or another supported event type.
However, before I model several events, I clarify the requirement:
- Must both events occur?
- Is only one of several events required?
- Must the events occur in a specific order?
These requirements lead to different BPMN structures.
If my process must receive two independent events and continue only after both have occurred, I model two parallel waiting paths.
Why Two Catch Events in Sequence Can Be Wrong
Suppose I model this sequence:
Task A → Event 1 → Event 2 → Task B
This structure defines an order. The process first reaches Event 1 and waits there. Only after Event 1 occurs does the token move to Event 2.
Therefore, the process does not actively wait at Event 2 while it is still waiting at Event 1.
Whether an earlier occurrence of Event 2 can still reach the process depends partly on the event type and the technical environment. For example, signals normally represent broadcasts and are not stored for a process that starts listening later. Message infrastructure, in contrast, may provide additional buffering or correlation mechanisms.
I therefore do not rely on an event being stored unless the process architecture explicitly guarantees that behavior.
Instead, I make the waiting requirement visible in the BPMN model.
How I Model Two Required Events
I use a parallel gateway before the intermediate catch events and another parallel gateway after them.
1. Complete the preceding activity
First, I model the activity that must finish before the process starts waiting. In this example, User Task A represents that activity.
After the task completes, the process can prepare to wait for both events.
2. Split the process with a parallel gateway
Next, I add a parallel gateway after User Task A.
The parallel gateway creates two active sequence flows. In BPMN, this is an AND split. Therefore, the process does not choose between the paths. It activates both.
The parallel gateway allows the process to reach both waiting positions independently.
3. Add one intermediate catch event to each branch
Then, I place one intermediate catch event on each branch.
In the example, one branch waits for User System Event 1. The other waits for User System Event 2.
As soon as the parallel gateway creates both paths, both catch events can become active independently. Therefore, Event 1 can occur first or Event 2 can occur first.
The process does not impose an order between them.
4. Synchronize both paths with another parallel gateway
After the two events, I connect both branches to a second parallel gateway.
Here, the gateway works as an AND join. It synchronizes the incoming sequence flows.
If Event 1 occurs first, its token reaches the gateway and waits. If Event 2 occurs first, the same principle applies to the other path.
Only after both tokens arrive can the process continue.
The first parallel gateway means “wait for both independently,” while the second means “continue only when both are complete.”
5. Continue with the next activity
Finally, I connect the synchronizing gateway to User Task B and then to the end event.
The complete process now expresses a precise requirement:
- Complete User Task A.
- Start waiting for both events.
- Accept the events in any order.
- Wait until both have occurred.
- Start User Task B.
- End the process.
Why This BPMN Pattern Works
The pattern separates two different concerns.
First, the AND split activates both waiting paths. Therefore, the process can wait for both events at the same time.
Second, the AND join synchronizes the paths. Therefore, the process cannot continue until both branches have completed.
The order of the events no longer matters.
For example:
Event 1 → Event 2 → continue
and
Event 2 → Event 1 → continue
produce the same process result.
I use this pattern when the business requirement says that both events are mandatory but their order is irrelevant.
When I Do Not Use a Parallel Gateway
The parallel gateway is not the correct solution for every group of events.
If I want the process to continue as soon as one of several alternative events occurs, I normally use an event-based gateway instead. In that case, the events compete with each other. The first event determines the path.
That represents a different requirement:
- Parallel gateway: I need Event 1 and Event 2.
- Event-based gateway: I need Event 1 or Event 2.
- Sequential catch events: I need Event 1 and then Event 2.
This distinction is important because the diagrams may look similar while describing very different process behavior.
A Practical Modeling Risk
The AND join also creates an important consequence. If one required event never occurs, the process waits indefinitely.
Therefore, I check whether the business process needs an escalation or timeout. For example, I may add timer logic when an expected response must arrive within a defined period.
A correct BPMN model should describe not only the successful path, but also what happens when an expected event never occurs.
Conclusion
When I model multiple BPMN intermediate events, I first define the required event relationship. If the process must receive both events in any order, I activate two parallel branches, place one catch event on each branch, and synchronize them with another parallel gateway.
This structure clearly communicates concurrency and synchronization. Moreover, it prevents me from accidentally modeling an event order that the business requirement does not contain.
For two mandatory independent events, the core pattern is simple: parallel split, separate catch events, parallel join, then continue.
What’s Next?
Now that I understand the BPMN foundation, I need to look at communication inside the model. A process often does not run in isolation. It exchanges information with people, systems, and other participants. That is why the next article is important. In Understanding Message Events in BPMN 2.0, I explain how BPMN shows sending, receiving, and waiting for messages. After that, I move to the people behind the model. In BPMN Project Roles for Effective BPM, I explain who takes part in BPMN work and how each role supports better process models. Therefore, these next steps help me connect BPMN knowledge with real communication and real project practice.
Explore Processes and Requirements Modeling
Processes help me understand how work moves from idea to result. In my main article on Processes, I connect the full picture. I explain how Process Management helps me structure, analyze, and improve workflows. Then I show how BPMN turns these workflows into clear visual models. In addition, I explain how Camunda supports BPMN modeling in a practical way. Therefore, this guide is the right next step if you want to understand processes, model them clearly, and improve them with confidence.
However, process models are only one part of a larger modeling landscape. That is why I also recommend my main article on Requirements Modeling. There, I connect Modeling Concepts, Process Modeling with BPMN, and UML. As a result, this second guide helps me understand how different modeling approaches work together and how I can choose the right model for the right purpose.
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 |