Skip to main content

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.

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

FieldDescription
BranchesThe 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 and 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 — 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.
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.

​
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 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 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 branches converging downstream.