Run approvers in parallel
What this achieves
Section titled “What this achieves”A parallel branch asks several people at the same time instead of one after another, which removes the waiting between them. You choose what finishing means: everybody must answer, or the first answer settles it.
Required role: Administrator.
- Open the workflow’s draft version in the designer.
- Drag a Parallel Split step onto the canvas and connect the step before it.
- Draw a line from the split to each approval step that should run at the same time. Each line is one branch.
- Drag a Parallel Join step onto the canvas and connect every branch into it.
- Select the join and open the Config tab.
- Choose the Join Strategy.
- Choose the Approval decision policy if the branches are approvals rather than tasks.
- Set Timeout (minutes) and, if you set one above zero, choose the On Timeout action.
- Select Save, then Validate.
Splitting and joining
Section titled “Splitting and joining”Every line out of the split becomes its own branch, running at the same time as the others. The join is what waits for them and decides when the route may continue.
Example: HC Corp asks Daniel Okonkwo in Finance and Sophie Clarke in the People team to approve a promotion at the same time. Neither is waiting on the other, and the promotion moves at the speed of the slower one rather than the sum of both.
A branch without a join has nothing to merge it back, which is one of the things validation checks before you can publish.
Choosing what finishing means
Section titled “Choosing what finishing means”| Option | Description |
|---|---|
| Wait for All | Every branch must finish before the route continues. |
| Wait for Any (first wins) | The first branch to finish releases the route. |
For branches that are approvals, the decision policy adds the outcome to that rule:
| Option | Description |
|---|---|
| None — use join strategy above | The join waits as the strategy says and does not route on approved or rejected. |
| All must approve — any rejection halts | Every approver must approve. The first rejection stops the branch immediately, rather than leaving the other approvers with tasks that no longer matter. |
| Any one approves — first approval advances | The first approval releases the route and the remaining tasks are cancelled. |
Setting a decision policy means the join routes by outcome, so it needs two lines out of it — one for the approved result and one for the rejected result. The panel says so when you set the policy, and validation refuses a publish where those paths are missing.
Example: HC Corp uses All must approve on a promotion, because Finance and the People team are each accountable for their own part. It uses Any one approves on an out-of-hours authorisation with three named approvers, because there the point is that somebody is available.
When a branch never finishes
Section titled “When a branch never finishes”| Option | Description |
|---|---|
| Timeout (minutes) | How long the join waits before the timeout action runs. Zero means it waits indefinitely. |
| Proceed | The route continues with whatever has been decided. |
| Cancel | The route is cancelled. |
| Escalate | The waiting work is escalated. |
Example: an all-must-approve join with a timeout of 2,880 minutes and Escalate means a promotion left undecided for two days is escalated rather than sitting between two departments indefinitely.
Choose Proceed with care on an all-must-approve join. It means the route continues without one of the approvals you said you needed.
What happens next
Section titled “What happens next”When the route runs, each branch produces its own task in its own approver’s inbox with its own deadline. The join applies the strategy and policy you set, and the instance view shows which branches have finished and which are still waiting.
Related
Section titled “Related”© 2025-2026 Humavera Documentation - BPilot Ltd. All Rights Reserved