Working With Decision Branches

Decision Branch nodes enable you to create separate paths for a runbook to execute, depending on the evaluation of a logical statement. They provide conditional logic that routes runbook execution through different sequences of nodes based on the data or conditions you specify.

Decision Branch nodes work in all runbook types. The specific data available for evaluation depends on the runbook type and the nodes that precede the Decision Branch.

How Decision Branches Work

When a Decision Branch node executes, it evaluates one or more conditions against the data it receives from the preceding node. The node checks each output condition in order. Execution follows the first path where the condition evaluates to true. If no conditions match, execution follows the default output path (if one is configured).

The data available for evaluation depends on what the preceding node forwards. This can include:

  • Metrics from Data Query nodes

  • Runtime variables set earlier in the runbook

  • Data properties from Transform nodes

  • Triggering entity information in incident runbooks

Each output path from a Decision Branch can connect to multiple nodes, allowing you to build complex investigation sequences that branch and rejoin as needed.

Configuring Decision Branches

To configure a Decision Branch node, you define one or more outputs, each with its own condition. For each output:

  1. Specify what to evaluate (a variable, metric, or data property).

  2. Choose a comparison operation (equals, greater than, less than, and so on).

  3. Provide the value to compare against.

  4. Optionally, assign a custom label to the output connector to make its purpose clear on the canvas.

You can also add a default output that executes when none of the other conditions match. This detail is useful for handling unexpected values or providing fallback behavior.

Note: The Decision Branch properties are context-sensitive, meaning the available options change based on what data the preceding node forwards. For example, if the preceding node forwards metrics, you'll see metric-related options. If it forwards variables, you'll see variable-related options.

Common Use Cases

Decision Branches are useful in many scenarios:

  • Routing by metric type: Direct investigation to different paths based on which metric triggered an incident. For example, route Interface Status incidents to one investigation path and Packet Error Rate incidents to another.

  • Threshold-based processing: Evaluate metric values against thresholds and route to different handling paths. For example, if throughput exceeds 10 Mbps, show high-throughput analysis; otherwise, show low-throughput analysis.

  • Variable-based routing: Use runtime variables to determine execution paths. For example, in a webhook runbook, route to different remediation paths based on the alert name received in the webhook payload.

  • Multi-metric analysis: Separate different metrics into their own investigation sequences. For example, create separate branches for mean opinion score, response time, throughput, and retransmission percentage, each with its own set of queries and visualizations.

Example: Simple Threshold Check

In an on-demand runbook, you might use a Decision Branch to route based on a throughput threshold:

  • Output 1: If Throughput is greater than 10 Mbps, route to a High Throughput Table visualization.

  • Default Output: Otherwise, route to a Low Throughput Table visualization.

This example creates two distinct investigation paths from a single data query, allowing the runbook to provide different analysis based on the actual metric values.

Example: Multi-Path Metric Routing

In an incident runbook, a Decision Branch can separate different metrics into their own investigation sequences. For example, following an Application Issue trigger, a Decision Branch might create four outputs:

  • Output 1: Route mean opinion score (MOS) incidents to MOS-specific queries and visualizations.

  • Output 2: Route response time/RTT incidents to response time analysis.

  • Output 3: Route throughput incidents to throughput analysis.

  • Output 4: Route retransmission percentage incidents to retransmission analysis.

Each output can then connect to multiple Data Query nodes and visualizations, creating comprehensive but focused investigation paths for each metric type.