⫸ Parallel
Splits workflow execution into multiple named branches that run simultaneously. All branches
must complete before execution continues past the merge point.
Category: Flow Control · Type identifier: parallel
Overview
Some workflows need to gather data from several sources before they can do anything useful
with it. Without the Parallel node, those requests would run one after another, with each
step waiting for the previous one to finish. The Parallel node removes that waiting — all
branches start at the same time and run concurrently. The workflow then automatically waits
at the merge point until every branch has finished before moving on.
This is especially valuable for API fan-out patterns: fetching a user's
profile, their recent orders, and their notification preferences all in a single step, then
combining the results into one email or document.
Each branch is identified by a name you choose. After all branches complete, their outputs
are available as properties of the Parallel node's output object, keyed by branch name.
All-or-nothing. If any single branch fails, the entire Parallel node fails
and subsequent steps do not run. Make sure each branch handles errors gracefully, or use a
Logic Gate after the parallel merge to check for missing data.
Configuration
| Field |
Status |
Description |
| Branches |
Required |
An array of branch names. Each name creates one output port (in graph mode) or one labelled execution lane (in linear mode). Use short, descriptive names like fetch_users, fetch_orders, fetch_products. |
Output Data
After all branches complete, the Parallel node produces a single output object. Each key in
that object corresponds to a branch name, and its value is the output of the last step in
that branch.
{{ parallel_step.output.fetch_users }}
{{ parallel_step.output.fetch_orders }}
{{ parallel_step.output.fetch_products }}
{{ parallel_step.output.fetch_users.name }}
{{ parallel_step.output.fetch_orders.total }}
Example Usage
Fan out to three APIs, then merge into one email
-
Add a Parallel node with three branches:
fetch_profile, fetch_orders, fetch_preferences.
-
In graph mode, draw edges from each branch output port to the first
node in that branch:
- fetch_profile → HTTP Request to
/api/users/{{ trigger.output.user_id }}
- fetch_orders → HTTP Request to
/api/orders?user_id={{ trigger.output.user_id }}
- fetch_preferences → HTTP Request to
/api/preferences/{{ trigger.output.user_id }}
-
After the merge point, add a Send Email node. Reference all three
branches in the email body:
Hello {{ parallel_step.output.fetch_profile.first_name }},
You have {{ parallel_step.output.fetch_orders.count }} recent orders.
Your notification setting is: {{ parallel_step.output.fetch_preferences.email_frequency }}.
Tips & Notes
-
Use meaningful branch names. Branch names become the keys in the output
object. Clear names like
fetch_user_details make your templates easier to
read than generic names like branch_1.
-
Each branch can contain multiple steps. A branch is not limited to a
single node. In graph mode, you can chain several nodes inside a branch — the output of
the last node in the branch is what gets collected at the merge point.
-
Parallel vs Loop. Use Parallel when you know the branches in advance and
each branch does something different. Use Loop when you have a
dynamic list of items and each item needs the same steps applied to it.
-
Rate limits. Running multiple HTTP requests simultaneously may trigger
rate limits on external APIs. If that is a concern, use a Loop
with a Wait node instead to pace the requests.
Related Nodes
- Loop — iterate over a dynamic array sequentially.
- Switch — route to exactly one branch based on a value (mutually exclusive, not concurrent).
- Logic Gate — test conditions on merged results after all branches complete.