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

# Parallel step

> Run the same group of steps for every item at the same time, instead of one after another.

The Parallel step runs a group of steps once per item — like a [Loop](/workflows/steps/loop), but all at once instead of one after another. It is a **container**: the steps that fan out live inside it on the canvas, and everything after it connects to its bottom edge.

Use it when the items have nothing to do with each other and the time adds up. Five API calls that take two seconds each take two seconds here, not ten.

## Setting it up

Drop a Parallel node on the canvas and it appears as an empty container with a **+** inside it. That **+** adds the first step of the body; the handle on the container's bottom edge is where the workflow continues once every branch has finished.

| Run                         | What you supply                                   | Branches     |
| --------------------------- | ------------------------------------------------- | ------------ |
| **Once per item in a list** | A list expression, e.g. `{{ fetch_users.users }}` | One per item |
| **A fixed number of times** | A number, or an expression returning one          | That many    |

An empty list runs nothing and the workflow carries on — that is not an error.

**At most, at a time** — how many branches may run simultaneously. The default is `5`; anything beyond it waits for a slot. The maximum is `20`.

**If a step inside a branch fails** —

| Option                           | Behavior                                                                                                                |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **Stop the whole run** (default) | The run fails. Branches already running are allowed to finish — they cannot be interrupted — but nothing further starts |
| **Record it and keep going**     | That branch's result is `null`, the failure is recorded, and the rest continue                                          |

## Referencing data

Inside a branch:

| Expression       | Value                                                        |
| ---------------- | ------------------------------------------------------------ |
| `{{ n4.item }}`  | This branch's item. In *fixed number* mode this is the index |
| `{{ n4.index }}` | Which branch this is, counting from **0**                    |
| `{{ n4.total }}` | How many branches there are                                  |

After the step:

| Expression            | Value                                      |
| --------------------- | ------------------------------------------ |
| `{{ n4.results }}`    | One entry per item, **in list order**      |
| `{{ n4.iterations }}` | How many ran                               |
| `{{ n4.errors }}`     | Each entry is `{ "index": …, "error": … }` |

`n4` stands for the step's own id — replace it with yours. The inspector prints the right one for you.

Results come back in list order no matter what order the branches actually finish in, so `{{ n4.results[0] }}` is always the first item's result.

A branch's result is whatever the **final** step of the body produced — same rule as the Loop.

## Branches cannot see each other

Each branch runs against its own private copy of the workflow's data. That is what makes running them at once safe, and it has two consequences worth knowing:

* **A branch cannot read what another branch produced.** There is no `results` to look back at mid-run, the way a Loop has.
* **After the step, the body steps' own outputs are gone.** Only `{{ n4.results }}` survives. With a Loop you can read a body step's last-iteration output afterwards; here you cannot, so anything you need must come out through the body's final step.

## How many items

The ceiling depends on how the workflow runs, because every branch happens inside the one call:

| Execution                                          | Maximum items |
| -------------------------------------------------- | ------------- |
| [Asynchronous](/workflows/execution/sync-vs-async) | 200           |
| Synchronous                                        | 10            |

Going over the limit fails the step with a message saying which limit applied. For a larger fan-out, run the workflow asynchronously.

## What cannot go inside

The workflow will not save if a branch contains any of these:

* **A Wait step.** Branches overlap, so there is no single point for the run to suspend at. Put the Wait before or after the container, or use a Loop instead.
* **Another Parallel step.** Nesting would multiply the number of things running at once.
* **An Output step.** An Output ends the workflow, which is ambiguous when several branches reach it at the same time. Put it after the container.

A Loop **is** allowed inside a branch, and a Parallel step is allowed inside a Loop body — each pass of the loop runs its own fan-out.

## Loop or Parallel?

| Use Parallel when                                  | Use Loop when                                                |
| -------------------------------------------------- | ------------------------------------------------------------ |
| The items are independent and latency matters      | A later item needs what an earlier one produced              |
| You are calling several APIs and want them at once | You are polling until something is ready — that needs a Wait |
| Order of execution does not matter                 | You want to stop early once a condition is met               |
|                                                    | You want a running total across items                        |

## Considerations

* **A branch with no steps inside does nothing** and the workflow continues — it will not fail the run.
* **The body must be self-contained.** A step inside the container cannot also be reachable from after it; the workflow will not save.
* **Concurrency is not a retry mechanism.** A failing branch fails once; there is no per-branch retry.
* **Everything happens inside one execution.** A very large fan-out of slow steps can still exceed the run's overall time limit, which is why the item ceilings exist.