> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spojit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Parallel

> Run multiple branches concurrently.

The **Parallel** node splits the workflow into multiple branches that execute at the same time.

## When to use

* Fetch data from multiple sources simultaneously
* Send notifications to different channels at the same time
* Perform independent operations that don't depend on each other

## Configuration

| Field        | Description                            |
| ------------ | -------------------------------------- |
| **Branches** | The number of parallel execution paths |

## Output handles

The parallel node has one output handle per branch. Connect a chain of nodes to each branch handle.

What happens *after* the branches depends on whether they converge downstream: see [Branches that don't merge](#branches-that-dont-merge) and [Branches that converge on a shared node](#branches-that-converge-on-a-shared-node) below.

## Branches that don't merge

If each branch ends on its own without feeding into a shared downstream node, the workflow completes once every branch completes. Results from each branch stay available as named variables, but there's no explicit "wait and continue" step.

```
                    ┌── Branch 1 → Send Slack message
Trigger → Parallel ─┤
                    ├── Branch 2 → Send email (Resend)
                    └── Branch 3 → Update spreadsheet
```

All three actions run at the same time. The workflow completes after all three finish, and there's nothing to do after them.

## Branches that converge on a shared node

If two or more branches feed into the same downstream node, that node becomes an **implicit merge point**. It waits for *every* incoming branch to complete before it runs. This is how you chain work that depends on multiple parallel results.

```
                    ┌── Branch 1 → Fetch users ───┐
Trigger → Parallel ─┤                             ├── Summarise results → Send email
                    └── Branch 2 → Fetch posts ───┘
```

`Summarise results` has two incoming edges, so it waits for both `Fetch users` and `Fetch posts` to complete before running. It then has access to both branches' outputs via their output variables.

<Note>
  You don't need a dedicated "Merge" or "Join" node; the workflow automatically detects any node with two or more incoming connections as a merge point. The compiler will also warn you about unintentional merges so you notice when an edge creates a wait-for-all that wasn't intended.
</Note>

## Fire-and-forget branches

Every branch of a parallel node **gates** the downstream merge: if any branch is still running, the merge node doesn't fire. If you want a branch that runs in the background without blocking anything (true fire-and-forget), use a [Subworkflow](/workflow-editor/nodes/subworkflow) node with its execution mode set to **async**. Async subworkflows kick off and return immediately; the parent workflow doesn't wait for them.

## Passing data between branches and the merge

Each branch's output is stored under its activity's **result name**, not lost when branches converge. In the convergence example above, the `Summarise results` node can reference both branches' outputs via `{{ users }}` and `{{ posts }}` in its prompt/config, assuming those are the result names you set on the fetch nodes.

See [Passing data between nodes](/workflow-editor/passing-data) for the full templating reference.

## Tips

* Use parallel execution to speed up workflows that make multiple independent API calls.
* If branches depend on each other in sequence, use separate sequential nodes, not a parallel block.
* Each branch can contain any combination of nodes: actions, conditions, loops, nested parallels.
* The same merge-point behavior applies to [Condition](/workflow-editor/nodes/condition) branches converging downstream.