Parallel Split

Fires all N of its outgoing branches simultaneously. Each branch runs independently; a failure on one does not stop the others. Use alongside Merge downstream to wait for all branches to complete.

When to use

• You have independent work that can happen in parallel — e.g. "Send email AND post to Slack AND update CRM — do all three at once."
• You want to minimize workflow latency when none of the branches depends on another.
• Fan-out patterns: one input triggers many downstream calls.

Configuration

Field	Required	What it does
branchCount	Yes	Number of output branches (2-10). Default 2.

Each branch becomes an outgoing handle branch_0, branch_1, … branch_N-1.

What it outputs

Nothing directly. Execution is simply routed to all N branches in parallel. To collect results from all branches, feed them into a Merge node.

Pattern: fan-out + fan-in

[Trigger] → [Parallel Split] → [Branch 0: send_email] →
                            ↘ [Branch 1: post_slack]  → [Merge (wait_all)] → [Next step]
                            ↘ [Branch 2: update_crm]  ↗

With Merge.mode = wait_all, the next step runs only after all three parallel branches finish. With first_wins, it runs as soon as any one finishes.

Gotchas

• Failure isolation: a crash on one branch doesn't stop the others. If you need all-or-nothing semantics, wrap each branch in a Try/Catch and check for failures at the Merge.
• Ordering: branches start at the same time, but their completion order is non-deterministic — depends on latency. Don't assume branch 0 finishes before branch 1.
• Context isolation: each branch writes to its own section of the context under the branch's node IDs. Branches cannot read each other's outputs mid-execution — that's what the Merge node is for.