Workflow Control Components

Use Fan Out and Fan In and Split and Merge to run parallel work and join results—wiring, configuration, and permissions.

This guide explains how to use control workflow nodes: Fan Out / Fan In and Split / Merge. These nodes help you run work in parallel and join results.

`Fan Out` and `Fan In`

What It Does

Fan Out expects incoming data to be a list. It starts one parallel branch per list item. Each branch receives one element of that list (not the whole list).
Fan In waits until every parallel branch that belongs to this fork has finished. It then passes a single list downstream: one entry per branch result.

Note

Do not rely on list order matching the original input order unless your process explicitly sorts it later.

These nodes do not show a configuration form in the library; you control behavior by wiring the graph and by ensuring the step before Fan Out outputs a list in the shape your downstream nodes expect.

How to Wire the Graph

Place Fan Out after a node whose output is a list (for example from a Transform, HTTP response parsing, or parameters).
Connect Fan Out with one outgoing edge to the first node that each parallel copy should run (every branch follows this same chain).
Connect the last step of that parallel chain to Fan In, then connect Fan In to whatever should run after all branches complete.

Empty List

If Fan Out receives an empty list, no parallel branches are created for that fork; the workflow does not execute the per-item path (there is nothing to fan out).

Example

Goal: Run a step once per IP address, then handle all results together.

Fan Out receives args that include a list of IP addresses, for example:

["192.0.2.1", "192.0.2.2", "198.51.100.10"]

Fan Out → a per-IP step (each branch gets one IP) → Fan In → a node that accepts a list of per-branch results.

Fan In output is a list of JSON objects—one per IP—with fields such as ip and verdict:

[
  { "ip": "192.0.2.1", "verdict": "clean" },
  { "ip": "192.0.2.2", "verdict": "suspicious" },
  { "ip": "198.51.100.10", "verdict": "clean" }
]

`Split` and `Merge`

What It Does

Split takes one payload and runs several branches in parallel. Each branch receives a full copy of the same payload (not different slices of a list).
Merge waits until all Split branches have finished, then passes one value to the next node:
- If every branch produced an object (key/value map), Merge combines them into one object: keys are merged, and when the same key appears in more than one branch, later branches override earlier ones for that key.
- Otherwise, the next step receives a list of the branch results (mixed types allowed).

Like Fan Out / Fan In, Split and Merge use the graph shape as the main control: branch count follows the number of outgoing edges from Split (draw one edge per parallel branch).

How to Wire the Graph

Place Split and Merge nodes on the canvas.
Connect Split to Merge, and add any other nodes that should run on each parallel path between Split and Merge.

Merge Output

If every branch outputs a JSON object, Merge combines them into one object (keys are merged; when the same key appears in more than one branch, later branches override earlier ones for that key).
Otherwise, Merge outputs a list of the branch results (mixed types allowed).

Example

Goal: Send the same notification payload to three channels at once, then continue with one combined outcome.

Split → three branches (email node, chat node, ticket node), each receiving the same payload.
Merge → a final step that either receives one merged object (if all three return objects) or a list of three results.

Workflow Control Components

On this page