Skip to main content
The Parallel step runs a group of steps once per item — like a 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. 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 —

​
Referencing data

Inside a branch: After the step: 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: 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?

​
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.