Parallel Gateway
Splits the flow into branches that ALL execute concurrently, and as a join waits for ALL of them — BPMN's AND gateway. Diamond with a plus.
The Parallel Gateway has no conditions: as a split, every outgoing path gets a token; as a join, it holds until a token has arrived on every incoming path, then emits one. Fork and synchronize — the two halves of structured concurrency.
When to use and avoid
When to use
When independent work should run simultaneously to cut lead time (background check + document check).
To synchronize: continue only after all parallel branches are done.
Always in pairs (split + join) for readable, sound models.
When NOT to use
When only one path should run — Exclusive.
When the parallel paths depend on conditions — Inclusive.
Joining branches that might not all be active — the AND-join would wait forever for missing tokens.
Business example
Running checks concurrently
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- The Parallel Gateway split (highlighted) issues tokens to both branches unconditionally.
- Background check and Document verification run at the same time.
- The join (also highlighted) waits for both tokens before the process continues — the slower branch dictates the pace.
Differences
Parallel split vs multiple flows out of a task
Two unconditioned flows leaving a task also duplicate the token (implicit AND-split), but the explicit Parallel Gateway makes the intent unmistakable and gives the join a proper partner. Prefer explicit gateways.
FAQ
What if one branch never finishes?
The join waits forever — guard long branches with timer boundaries or deadlines so the synchronization can't hang.
Do branches see each other's data?
They share the instance's data context — concurrent writes to the same variables must be designed carefully.