All nodes/Logic & Flow/Synchronization

Split

Splits a combined execute_data input into separate exec and data outputs. Makes the separation of execution flow and data an explicit element of the graph.

Try it

When to use it

The inverse of merge: it takes one combined “execution + data” edge and separates it into two — “Success” continues the execution chain, “Data” carries the same value onward without any order to run. Useful when a step’s flow and its result must go in different directions: execution to the next action, the value into the data input of a template, a condition or a database write.

As with merge, look at the source node’s own settings first: many nodes offer a “Split output ports” toggle that does the same thing without a separate box. Reach for split when there is no such toggle, or when you want the fork to be explicit.

How it works

One edge comes in. The “Data” output carries the whole payload unchanged: {{ nodes.<id>.output }} returns exactly what arrived.

The difference between the outputs is not the value but what they do to ordering. “Success” starts the next node. “Data” only hands over the value: the receiver reads it when it runs. If nothing else can start that receiver — it has no other execution input — Flow starts it from this data edge so the branch does not go dead.

Common mistakes

• The data edge is drawn but the value is missing. That happens when the receiver ran earlier along its own execution path: the value is read at the moment it runs. If order matters, route “Success” into the receiver too, not just “Data”.
• Wiring “Data” into an execution input. The data output carries no order to run; use “Success” for sequencing.
• Expecting the node to extract or unpack something. split does not touch the content — it separates execution from data. To pull a field out of an object, address it in a template: {{ nodes.<id>.output.<field> }}.

Inputs

Outputs

Configuration

This node has no configurable fields.