Event-Based Gateway
Routes by WHICH EVENT HAPPENS FIRST: the process waits at the gateway, and the first event to occur (message, timer, signal…) chooses the path. Diamond with a pentagon inside a double circle.
The Event-Based Gateway models a race: after it, each outgoing flow leads to a catching event (or receive task); the first to trigger wins, and the other branches are discarded. The canonical pattern: *reply received* vs *timeout*.
When to use and avoid
When to use
For reply-or-timeout waits after sending a request.
When the next step depends on which of several external stimuli arrives first.
To model deferred choice — the environment, not data, decides.
When NOT to use
When data already answers the question — Exclusive Gateway.
With activities directly on the outgoing flows — only catching events / receive tasks are allowed.
For racing more than a handful of events — consider restructuring for readability.
Business example
Supplier reply vs 48-hour timeout
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- Send request to supplier dispatches the RFQ.
- At the Event-Based Gateway (highlighted), the process waits: whichever fires first — the supplier's reply or the 48-hour timer — wins.
- Reply → Process reply; timeout → Contact another supplier. The losing branch is discarded automatically.
Differences
Event-Based vs Exclusive Gateway
Exclusive: instant decision on available data. Event-Based: suspended decision — time passes, the environment answers. If the token must *wait* to know, it's event-based.
FAQ
What may follow an event-based gateway?
Only intermediate catching events (message, timer, signal, condition) or receive tasks — never ordinary activities or throw events.
What happens to the branches that lost the race?
Their event subscriptions are cancelled the moment the winner fires — no dangling waits remain.