---
title: 'Parallel Split'
description: 'Runs multiple branches concurrently — fan-out pattern.'
---
# 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.