Skip to main content
The merge node combines data from multiple upstream branches into a single output. Use it to bring together results from parallel processing paths, for example merging an extraction result with data fetched by an HTTP action.

​
When to use merge

  • Your graph fans out into parallel branches (one node feeding several) and you need to combine them before delivery. Use Key match when each branch produces records that share an identifier, Concat when you just want the lists end-to-end, Zip when items pair by position.
  • Your graph takes either one branch or another (a classify sends the document down one path) and you need to continue on a single node afterwards. Use First Available mode so the merge runs on the branch that arrived.
  • You cut a document up with split and need to reassemble the per-group outputs. Split’s groups become child runs rather than branches in this run, so gather them with Collect, not Key match, Concat or Zip.
  • You enriched data via an HTTP action and need to merge the response back with the original payload. Use Key match.
  • Skip merge when only one branch reaches the output node; merge expects multiple sources.

​
Require all sources

Key match, Concat and Zip show a Require all sources switch, on by default. It controls what happens when a connected branch does not deliver.
  • On: the merge waits for every connected source and runs only once all of them arrive. A branch that was skipped counts as not arrived, and so does a branch that ran and failed. Either way the merge is skipped, and every node downstream of it is skipped with it. Read the merge step’s skip reason in the run detail: it names the branches whose input did not arrive. The terminal status differs between the two cases. If the missing branch was skipped, nothing failed, so the run still finishes as completed even though the outputs downstream of the merge never ran. If the branch ran and failed, and no failure edge handles that failure, the run finishes as failed.
  • Off: the merge runs on whatever arrived, and sources whose branch was skipped or failed are left out of the result. This is the setting that makes either/or joins work, for example a classify sending a document to branch A or branch B and a merge joining the two back into one path. The merge is still skipped when nothing arrived at all.
Turning the switch off changes only this node. Every other node keeps waiting for all of its inputs.

​
Merge modes

Select a merge mode to control how data from multiple sources is combined.

​
Key match

Match items across sources by a shared property and merge their fields into combined objects. For example, if source A produces [{ lineNum: 1, text: "Hello" }] and source B produces [{ lineNum: 1, confidence: 0.95 }], key matching on lineNum produces [{ lineNum: 1, text: "Hello", confidence: 0.95 }]. Add one entry per pair of arrays under Merge Sources. Configuration: Two entries that resolve to the same target path are rejected when you save the workflow. Name at least one of them explicitly.

​
Concat

Append outputs from multiple sources end-to-end into a single list. For example, if source A produces [{ line: 1 }, { line: 2 }] and source B produces [{ line: 3 }], concat produces [{ line: 1 }, { line: 2 }, { line: 3 }]. Configuration:

​
First Available

Output the first source whose branch ran, in the order you list them. Use this for either-or joins, where an upstream branch point sends a run down exactly one path and you want to continue on a single node afterward, whichever path ran. For example, a reconcile node sends matched rows directly into a merge node, and routes mismatched rows through a review task first, which also feeds the same merge node - both branches join at the merge, which then continues on to the output node. A source is readable only when its connection into the merge actually fired, so on any given run exactly one of {{reconcile.payload.lines}} and {{review.payload.lines}} resolves; both can no longer resolve at once. Source ordering in Sources is not load-bearing here as a result - list either one first. Downstream nodes read the result at {{merge.payload.items}}. For a join this simple, {{$input.*}} is the simpler answer: it resolves to whichever branch fired without needing a Merge node at all. Configuration:
  • Resolved beats empty: a branch that ran and produced an empty list is an answer, not a miss. If the review branch ran and the reviewer removed every line, the merge outputs that empty list rather than falling through to reconcile’s data. Only a branch whose connection into this merge fired is considered.
  • Sources must match: every source must resolve to the same type of value. Mixing a list with a plain value, for example, is a validation error that blocks activation.
  • Require all sources is always off: an either-or join always has a branch that did not run, so this mode forces the switch off and hides it.

​
Zip

Pair items by index position from multiple sources into combined objects. For example, if source A produces [{ page: 1 }, { page: 2 }] and source B produces [{ text: "Hi" }, { text: "Bye" }], zip produces [{ page: 1, text: "Hi" }, { page: 2, text: "Bye" }]. Configuration: Include All keeps every index, and a source that ran out of items contributes no properties at those positions. It does not pad them with nulls.
Zip works on arrays of objects. A source whose items are scalars (strings, numbers, booleans) fails the step with an error naming the source and the index. Earlier releases accepted such a source and emitted empty objects like [{}, {}]. Wrap the scalars in objects first, for example with a transform node.

​
Collect

Gather outputs from child runs (created by a split or classify node) into one array. Use this when a split node cuts a document into multiple child runs and you need to reassemble the results. Connect the split or classify node directly to the merge node on the canvas. The edge is saved as a post-children join automatically, so the merge runs once in the parent run after every child run has finished. There is no edge setting to pick. Two rules apply:
  • The merge must be in Collect mode. In any other mode the connection is rejected, because the merge resolves its sources from expressions and the edge would only order the nodes.
  • The upstream node must actually create child runs. A classify in By example mode answers inline and creates none, so that connection is rejected.
Set Source Node Name to the name of a node inside the child workflow, and each child run’s output for that node is collected in the chosen sort order. Collect can also gather a node’s per-item outputs from inside a loop. Set Source Node Name to the name of a node within the loop body, and merge concatenates that node’s per-item results, in item order, into a single array. This runs after the loop completes and complements the split child run case. Configuration:

​
Inputs and outputs

Allowed inputs: Every action node except Filter and Parse, including another Merge, the connector nodes (Business Central and QuickBooks in any operation, and Callback), plus the Sub-workflow trigger. Split and Classify can connect only to a merge in Collect mode. Supports multiple input connections. Output: Combined data object from all configured sources. First Available mode is the exception: its output holds exactly one source’s value, the first listed source that resolved, at the configured target path. If no source resolves at all, the step fails with “No source could be resolved”.

Split action

Split data into branches before merging

Extract action

Extract data before merging

Transform action

Transform merged data into a specific format

Review action

Review merged data before delivery