Event-based gateways in BPMN help me model situations where the next step depends on an event, not a direct decision. This is useful when a process must wait for a message, signal, or response. In this article, I explain event-based gateways in BPMN in a clear and practical way. As a result, I can show how event-driven process paths work and why they matter in real workflows.
What Is an Event-Based Gateway in BPMN?
I use an event-based gateway when a process reaches a point where it must wait for one of several possible events.
The gateway does not evaluate a condition. Instead, it activates several possible event alternatives and waits.
For example, a process may wait for:
- a customer response,
- a cancellation message,
- a payment confirmation,
- or a timer to expire.
As soon as one relevant event occurs, the process continues along the corresponding path.
An event-based gateway lets the event that happens first determine how the process continues.
Therefore, I use this gateway for event-driven decisions rather than data-driven decisions.
How I Recognize an Event-Based Gateway
BPMN represents a gateway with a diamond. The event-based gateway contains a double circle and a pentagon inside that diamond.
This symbol matters because several gateway types use the same basic diamond shape. The internal marker tells me which behavior applies.
However, the symbol alone does not make a model correct. I also need to structure the outgoing paths according to the rules of the gateway.
How an Event-Based Gateway Works
The behavior follows a clear sequence.
First, a token reaches the event-based gateway.
Next, the process starts waiting for the events associated with its outgoing paths.
Then, one of these events occurs.
Finally, the process continues along that path.
With the standard exclusive event-based gateway, the remaining alternatives no longer compete after one event wins.
The gateway does not choose an event. It waits until reality determines which event occurs first.
Consider a simple example. I send a customer a request for additional information. Afterward, I wait for either a reply or a timeout.
If the customer replies first, I process the response.
However, if the deadline expires first, I follow the timeout path.
This is the core use case for an event-based gateway.
Event-Based Gateway vs. Exclusive Gateway
I consider this distinction essential.
Both gateway types can lead to one alternative path. However, they determine that path differently.
| Exclusive gateway | Event-based gateway |
|---|---|
| Evaluates existing information | Waits for a future event |
| Uses conditions | Uses catching events |
| Makes the choice immediately | May wait before continuing |
| Example: Is the order above €1,000? | Example: Does the customer reply before the timeout? |
An exclusive gateway answers a question with information that already exists.
For example:
Is the invoice amount above €10,000?
If the answer already exists in the process data, I use an exclusive gateway.
In contrast, an event-based gateway waits for something that has not happened yet.
For example:
Will the customer approve the offer, reject it, or fail to respond before the deadline?
If existing data determines the path, I use a data-based gateway. If a future event determines the path, I consider an event-based gateway.
This simple rule prevents many modeling mistakes.
Correct Structure After an Event-Based Gateway
The elements after an event-based gateway require special attention.
I normally connect each outgoing sequence flow to an intermediate catching event or a Receive Task. Those elements represent what the process waits for.
For example:
Event-Based Gateway → Message received → Process response
Event-Based Gateway → Timer expired → Escalate request
Event-Based Gateway → Cancellation received → Close request
I do not normally connect the gateway directly to an ordinary task such as “Process Response.”
Why?
Because the task describes what I do after an event. It does not describe the event that determines why the process selected that path.
The event must determine the path before the activity on that path begins.
This distinction makes the BPMN model both clearer and more accurate.
A Practical Customer Support Example
Suppose I model a support process.
A support team asks a customer for more information. The process now has to wait.
Three outcomes matter:
- The customer sends the requested information.
- The customer cancels the request.
- The customer does not respond within 48 hours.
I can model these alternatives with one event-based gateway.
The first outgoing path leads to a message catching event such as “Information received.” Afterward, the process continues with “Review information.”
The second path leads to “Cancellation received.” Then, I close the case.
The third path leads to a timer event such as “48 hours.” If that timer occurs first, I send a reminder or escalate the request.
Therefore, the gateway expresses the actual business logic precisely.
The process does not decide whether the customer responds. Instead, it waits to see what happens.
Why a Timer Is Especially Useful
I often combine an event-based gateway with a timer event.
Without a timer, a process could theoretically wait forever.
For example, suppose I request approval from a customer. I can wait for either:
Customer approval
or
Seven days elapsed
If approval arrives first, I continue with the approved case.
Otherwise, the timer starts another path after seven days.
This makes deadlines explicit in the process model.
A timer event gives an event-based gateway a clear alternative when the expected external event never occurs.
As a result, readers can immediately understand both the expected response and the fallback behavior.
Event-Based Gateway vs. Parallel Gateway
I do not use an event-based gateway to synchronize parallel work.
A parallel gateway has a different purpose. It can activate several paths at the same time. A corresponding parallel gateway can later wait until the required parallel paths arrive.
The standard event-based gateway does the opposite. Several events may be possible, but one event determines the continuation.
Therefore:
Parallel gateway → several paths proceed.
Event-based gateway → several events compete.
An event-based gateway represents competing future events, not parallel activities that need synchronization.
This also corrects a common misconception about tokens. I do not use the standard event-based gateway to wait for multiple tokens that arrive from different branches. It is not a synchronization gateway.
I Do Not Add Conditions to the Outgoing Paths
Conditions belong to data-based decision logic.
For example, I may define:
Amount > €1,000
Amount ≤ €1,000
That structure fits an exclusive gateway.
With an event-based gateway, the events themselves determine the alternatives. Therefore, I do not need conditions on its outgoing sequence flows.
Instead, I make the possible events visible.
For example:
Message received
Timer expired
Cancellation received
This structure communicates the logic much more clearly.
What Happens After the First Event Occurs?
Suppose a process waits for a message or a timer.
The timer expires first.
Therefore, the process continues through the timer path. The message alternative of that gateway no longer remains available for the same gateway instance.
However, this does not mean that the real-world message can no longer arrive.
A customer might still respond later.
Therefore, I must consider whether late events matter to the business process.
For example, I may need another mechanism to handle a late customer response after the case has already moved to escalation.
This becomes especially important when I design executable processes rather than diagrams for documentation only.
Common Mistake: Connecting the Gateway Directly to Normal Tasks
The attached diagram illustrates an important modeling issue.
It shows an event-based gateway followed directly by activities such as “Provide Automatic Solution,” “Agent Handles Request,” and “Provide Combined Assistance.”
However, these activities do not tell me which events caused the process to select each path.
For a proper event-based structure, I would first model the events.
For example:
Event-Based Gateway → Automatic response received → Provide Automatic Solution
Event-Based Gateway → Agent response received → Agent Handles Request
Event-Based Gateway → Defined event received → Provide Combined Assistance
Alternatively, if the process already knows which type of assistance the customer needs, I would not use an event-based gateway at all. I would probably use an exclusive or inclusive gateway, depending on the business logic.
Several possible outcomes do not automatically justify an event-based gateway. The process must actually wait for events.
That is the key modeling question.
When I Use an Event-Based Gateway
Before I add one, I ask three questions.
- Does the process need to wait?
- Can several different events occur next?
- Does the event that occurs determine the next path?
If I answer yes to all three questions, an event-based gateway may fit the process.
Typical use cases include waiting for a response or timeout, receiving one of several messages, reacting to a cancellation, or waiting for an external confirmation.
However, I do not use the gateway simply because a process has several alternatives.
When I Do Not Use an Event-Based Gateway
I avoid it when the process already has enough information to make a decision.
For example, I do not need an event-based gateway for:
Customer type = business or private
Order value above or below a threshold
Automatic check passed or failed
Risk score high, medium, or low
In these situations, the required data already exists. Therefore, I normally use an exclusive gateway or another suitable data-based gateway.
I also avoid an event-based gateway when I need several branches to run at the same time. In that case, a parallel gateway may fit better.
Finally, I do not use it to merge branches.
Choosing a gateway starts with understanding the process behavior, not choosing a symbol that looks convenient.
Event-Based Gateways in Executable BPMN
Event-based gateways become especially important when I automate a BPMN process.
A diagram may look understandable to a human while still containing logic that a workflow engine cannot execute correctly.
Therefore, I check the capabilities of the engine I use.
I pay particular attention to:
- supported catching event types,
- message correlation,
- timer configuration,
- cancellation of competing event subscriptions,
- and handling of late events.
This distinction matters because BPMN defines the notation and semantics, while a workflow engine implements a specific subset of that standard.
Therefore, I separate two questions:
Is the BPMN model semantically correct?
Can my chosen workflow engine execute it as intended?
Both questions matter.
Final Thoughts
Event-based gateways in BPMN solve a precise problem. I use them when a running process reaches a waiting point and several future events could determine what happens next.
They are not general decision gateways. They do not evaluate normal business conditions. They also do not synchronize parallel tokens.
Instead, they model competition between events.
I use an event-based gateway when the process must wait and the event that happens first determines the next path.
Once I understand that principle, the gateway becomes much easier to use. It also helps me create BPMN models that explain not only what the process does, but also what the process is waiting for and why it continues along a specific path.
What’s Next?
If I want to strengthen my BPMN foundation, the next step is to understand the essential building blocks of every process model. That is why I continue with BPMN Core Elements. In that article, I explain the main BPMN elements and show how they work together in a clear and practical way. As a result, I can read process diagrams more confidently, create better models, and understand business workflows with much more precision.
Explore Requirements Modeling and Processes
If I want to understand requirements in a deeper and more practical way, I need more than text alone. I need models that show how concepts, 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 clearly, communicate them more effectively, 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 practical improvement work. Click through to learn how Processes help me understand work better, improve collaboration, and create stronger business outcomes.
Credits: The diagrams were created with Camunda.
| Read more on Business Process Modeling and Notation (BPMN) |
|---|
| Syntax and Semantics of BPMN BPMN Project Roles for Effective BPM The Participant Perspective in BPMN BPMN Core Elements |