Inclusive Gateway (OR)
A diamond that routes the token down every outgoing path whose condition is true: one, some, or all of them.
What an inclusive gateway does
An inclusive gateway is a diamond with an "O" marker. Unlike the exclusive gateway, which picks exactly one path, the inclusive gateway lets the token go down *every* outgoing flow whose condition is true. Zero conditions matching means the default flow fires, one matching means one path, two or three matching means two or three parallel paths proceed at once.
Inclusive gateways are the natural fit for "any of" rules. "If the order is high-value, run the fraud check; if the customer is new, run identity verification; both conditions can be true". An exclusive gateway cannot express that. A parallel gateway cannot either, because parallel always fires every branch regardless of condition. Only the inclusive gateway captures "fire each branch whose condition holds, and synchronise on join when the fired ones finish".
The join problem
The tricky part is the merging side. A parallel gateway on join waits for every incoming path. An inclusive gateway on join must wait only for the paths that actually fired on the matching split, which is harder to compute because the join needs to know which paths were activated upstream. BPMN 2.0 requires engines to track this, but hand-drawn diagrams frequently get it wrong by using a parallel join for an inclusive split, which causes the process to hang waiting for branches that never fired.
Inclusive gateways in LucidFlow
LucidFlow uses inclusive gateways when the source document says "and/or": "notify the customer by email and/or SMS", "run KYC and/or AML checks when flagged". The generator emits a matching inclusive join at the synchronisation point so the semantics round-trip correctly to Camunda, Signavio, and other execution engines. The cost dashboard accounts for the probabilistic nature of inclusive branches by weighting each branch cost by its independent probability of firing.
Frequently asked questions
When do I actually need an inclusive gateway?
When two or more outcomes can genuinely fire at the same time and both need to complete before the process continues. If only one outcome ever fires, use exclusive. If all outcomes always fire, use parallel. Inclusive is strictly for the "some subset" case.
Can an inclusive gateway have a default flow?
Yes. If zero conditions match, the default flow is taken. The token does not just disappear. Best practice is always to include one, for the same reason as on an exclusive gateway.
Why do engines sometimes refuse to execute inclusive joins?
Because the join has to decide which incoming branches it is still waiting for, and that depends on which branches the matching split activated. Older BPMN engines did not implement the lookahead; modern ones (Camunda 8, Flowable) support it natively, but you still see the warning "inclusive gateway requires a matching split" in linters.