Merge

The Merge node Individual components that make up a runbook automation, each performing a specific function such as data queries, transformations, logic, integrations, or visualizations. waits for multiple incoming control paths to finish before the flow continues past it in the Runbook. It can have more than one parent node. The node does not return data and its output A document containing data sets generated by the execution of a runbook, including output of queries and reports from point products, as well as output of analysis or other runbook nodes. is empty, so the UI does not check data type and parent nodes have no output constraints.

The Merge node does not pass data to the next step. Put nodes on the incoming branches to write variables An entity type representing software applications deployed in the customer environment that are monitored for performance and anomalies., then put nodes after the Merge to read those variables. A typical pattern is to run several remediation scripts that each store results in variables, wait at the Merge until they have all finished, then run downstream nodes that use those values for more work or for display. To turn several branch outputs into one dataset, add a Coalesce node after the Merge.

The graph cannot loop back on itself. You can use the Merge node in a runbook An automated workflow that executes a series of steps or tasks in response to a triggered event, such as the detection of anomalous behavior generating an incident, a lifecycle event, or a manually executed runbook. or inside a subflow.

Behavior

The Merge node waits until all of its parent nodes have completed.

By default, the Merge node only runs when all parent nodes are completed successfully. If any parent node failed, the Merge node fails. If none of the parents failed, but some parents were abandoned because execution never took those paths in this run (for example, the side of a Decision Branch that was not selected), the Merge node is abandoned. You can change this behavior with the property settings.

For branches to count as abandoned in this way, the branching node must complete successfully. If a Decision Branch fails, paths that did not run are not abandoned. For example, the node might have two conditional outputs, one when a runtime variable An entity type representing software applications deployed in the customer environment that are monitored for performance and anomalies. equals one and another when it equals two, with no default output. If the variable equals three at run time, there is no successful condition evaluation. The Decision Branch fails. The Merge node does not treat the situation as successful branching with unused paths abandoned. One way to make the Decision Branch succeed when no named condition matches is to add a default output. You do not need to connect another node to that default output.

When a parent node ends in an error or a branch never reaches the Merge, those options control whether the run stops at the Merge node or continues.

The Merge node will never continue if:

• Every parent failed.

• Every parent was abandoned.

• No parent can be reached.

When the editor evaluates these outcomes, it only considers what happens on each path after the branches split from their shared starting point. Failures or unreachable nodes on the shared path above that split do not decide the result on their own.

Default settings by runbook type

When you first add a Merge node, the runbook editor sets starting values for branch handling from the node library for that runbook type.

• Incident and Lifecycle: Both settings below default to stopping the run when a parent path ends in an error or is abandoned before the Merge.

• On-Demand, External (Webhook), and Subflow: Both settings default to continuing the run when a parent path ends in an error or is abandoned before the Merge.

You can change these options at any time in the node editor.

Properties

Node Label: Type an informative name for the Merge node. You can keep the system-provided default of Merge if you wish.

If one incoming branch ends with errors: Choose Continue flow execution from here anyway to allow the Merge to run when at least one parent completed without failure and some parents failed. Choose Stop flow execution for all branches here to block the run at the Merge when any parent failed.

If one incoming branch normally ends its flow execution before reaching here: Choose Continue flow execution from here anyway to allow the Merge to run when at least one parent completed successfully and other parents were abandoned (for example, unused Decision Branch paths). Choose Stop flow execution for all branches here to block the run when any parent was abandoned.

When both branch-handling properties are set to continue, the Merge node can run when at least one parent completed successfully, even if every other parent failed or was abandoned.

Use that combination when a Decision Branch feeds the Merge and the Decision Branch completes successfully. In each such execution, only one branch runs, so the other branch is always abandoned. If you required every parent to succeed, the Merge would never run. Allowing abandoned branches lets the Merge complete after the branch that actually ran succeeds.

Runbook compatibility

Incident, Lifecycle, On-Demand, External (Webhook), and Subflow