Parallel Gateway (AND)
A diamond with a "+" that forks the token down every outgoing path at once, and waits for all of them on the join.
What a parallel gateway does
A parallel gateway is a diamond with a "+" marker. It forks: when the token arrives, a new token is spawned on *every* outgoing sequence flow, unconditionally. There are no branch conditions; parallel means "all of these, no choice". The gateway on the join side does the opposite: it waits for a token on every incoming flow before passing a single token through.
Parallel is the simplest gateway to execute but one of the trickier ones to design. Real business processes rarely have genuinely independent parallel paths. Most "parallels" turn out to be inclusive (optional) or exclusive (one of). Before modelling something parallel, ask: "do all of these paths always fire, no exceptions?" If not, you probably want inclusive.
Genuine parallel scenarios
- Independent side effects with no ordering: "notify the customer AND update the warehouse AND log to the audit trail" all fire for every order, in any order.
- Lead time optimisation: running two independent checks in parallel to halve elapsed time when either alone would take days.
- Fan-out data processing: parallel sub-processes that each handle a different dimension of the same input.
Parallel gateways in LucidFlow
LucidFlow uses parallel gateways sparingly, only when the source document describes genuinely concurrent, unconditional work ("in parallel we notify the customer and ship the order"). When the document is ambiguous ("we can run KYC and AML in parallel"), the generator prefers an inclusive gateway because "can" implies optionality. You can promote to parallel manually once you confirm the process always does both.
Frequently asked questions
Can a parallel gateway have conditions on its outgoing flows?
No. Conditions on outgoing flows of a parallel gateway are ignored by the spec. If you need conditional branching, use an exclusive or inclusive gateway. Parallel means "all, always".
What if I want parallel execution with a conditional join?
That is the classic pattern: parallel split to fan out work, inclusive join to wait only for the branches that matter, with explicit conditions on the incoming flows. BPMN 2.0 supports this via conditional-flow semantics on the join.
Do I need a parallel gateway at the end to synchronise?
Yes, if the downstream work depends on all forked paths completing. If the forked paths are "fire and forget" (each goes to its own end event), no join is needed.