Inclusive Gateway
Activates EVERY outgoing path whose condition is true — one, several or all — and as a join synchronizes only the paths that were activated. Diamond with a circle.
The Inclusive Gateway is the conditional multi-select: “notify by e-mail if opted in, by SMS if opted in, by letter if legally required” — any combination may fire. Its join is smart: it waits exactly for the branches that received tokens, not for all drawn ones.
When to use and avoid
When to use
For independent conditions that may each trigger their own action simultaneously.
Checklist-style activations: apply every treatment whose criterion is met.
With a default flow to guarantee at least one activation.
When NOT to use
Exactly one path → Exclusive. All paths always → Parallel.
When downstream logic can't handle a variable set of active branches.
In tools/engines with shaky inclusive-join support — verify before relying on it.
Business example
Notifying through every opted-in channel
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- The Inclusive Gateway (highlighted) evaluates both conditions independently: e-mail opted-in? SMS opted-in?
- Both true → both branches run; one true → just that one.
- The inclusive join (highlighted) waits precisely for the branches that fired, then continues.
Differences
Inclusive join vs Parallel join
The parallel join waits for tokens on *all* incoming flows. The inclusive join waits only for flows that were *actually activated* upstream — which is why it pairs safely with an inclusive split, and why mixing joins across gateway types breaks models.
FAQ
What if no condition is true?
Same trap as the exclusive: model a default flow, or the token dies at the gateway.
Why is the inclusive join considered tricky?
It must know which branches may still deliver tokens — engines implement non-trivial reachability logic. Keep inclusive sections simple and well-paired.