Input Data
The data a node sees when it starts — and the biggest misconception to unlearn: it is not simply "the previous node's output."
What It Actually Is
ProcessElementExecutionContext.InputData (Dictionary<string, object?>) is a flat bag of every variable currently visible to this node — built fresh for every node execution, from the workflow's scope chain, not copied from one specific upstream node.
ProcessElementExecutionSequencer.cs:102:
InputData = memory?.GetAllVisibleVariables() ?? new Dictionary<string, object?>()GetAllVisibleVariables() walks the current scope chain and merges every visible variable into one dictionary — parent scopes first, closer scopes overriding same-named variables.
How Fields Get Into That Bag
After each node finishes, its OutputData fields are written individually into the parent scope — not as one blob under the node's name:
// ProcessElementExecutionSequencer.cs:299-302
foreach (var kvp in nodeResult.OutputData)
{
parentScope.SetVariable(kvp.Key, kvp.Value);
}So if the HTTP Request node's OutputData has keys status, items, and count, those three become three separate scope variables. The next node's InputData is the union of all such variables still in scope — which can include fields from several nodes back, not just the immediately preceding one.
lastNodeResult, lastNodeOutput, and nodeOutput-{key} as whole-object variables. A comment at ProcessElementExecutionSequencer.cs:304-309 confirms these were deliberately removed as duplicate storage — OutputIndex (via RecordNodeExecution) handles historic tracking instead, and flat field storage is considered sufficient. If you're chasing an old reference to nodeOutput-XYZ, it no longer exists.
What This Means in Practice
| Question | Answer |
|---|---|
| Can two upstream nodes' fields collide? | Yes — if two nodes both produce a field called status, whichever ran more recently (closer scope) wins for anything reading InputData directly. |
| Does InputData include the node's own config? | No — config is resolved separately via the node's settings object, not through InputData. |
| Does InputData include a node's own prior OutputBranches? | No, not directly — but see Pinned Data for a case where a similar-shaped blob leaked in through a different path. |
| Is InputData the same object across the whole workflow? | No — a fresh dictionary is built via GetAllVisibleVariables() for every single node. |
The Standard items Convention
Most nodes read their real record-shaped input from one specific InputData key: items, in the standard [{ "json": {...} }, ...] envelope shape. A node unwraps this via the shared ExtractRecordsFromItems helper on BaseNodeExecutor, which pulls each entry's json value out — see Output Data for how that shape gets produced in the first place.