The Decision Node evaluates a set of conditions against runtime workflow data and routes execution down the matching branch. It is the equivalent of an if/else-if/else statement for your workflow. Each condition you define becomes a named output handle on the canvas, plus a mandatory Default handle that catches all cases where no condition matches.

The Decision Node executes instantly (no human interaction required) and advances the workflow immediately.

---

When to Use

Use a Decision Node when your workflow needs to follow different paths based on data:

• Route a leave request to different approval chains depending on the number of days requested.
• Skip an approval step entirely if the expense amount is below a threshold.
• Branch on the outcome of a previous Approval Node (approved vs. rejected vs. auto-approved).
• Check whether a form field is empty before proceeding.
• Evaluate any Data Center value — form submissions, API responses, system fields, or computed variables — and decide what happens next.

---

Configuration

Conditions

A Decision Node contains an ordered list of conditions. Each condition has a name, a unique ID, and a boolean expression that is evaluated at runtime.

Conditions are evaluated in order, top to bottom. The first condition that evaluates to true wins — the workflow follows that condition's output handle and skips all remaining conditions. If no condition matches, the workflow follows the Default handle.

This is important: the evaluation is short-circuit. Once a match is found, subsequent conditions are not evaluated.

Condition Expressions

Each condition's expression is a structured boolean tree with two levels of nesting:

Top level — a list of rule groups joined by a combinator (AND or OR).

Each rule group — a list of individual rules joined by their own combinator (AND or OR).

This two-level structure lets you build complex logic like: (Department = "Engineering" AND Level > 5) OR (Department = "Finance" AND Level > 3).

Individual Rules

Each rule within a group consists of three parts:

Available Operators

The set of operators available depends on the data type of the field:

String fields: Contains, Does not Contain, Equals (case-sensitive), Equals (non case-sensitive), Not Equals, Is Null, Is not Null, Is Empty, Is not Empty.

Number fields: Less than, Greater than, Equal to, Not equal to, Less than or equals, Greater than or equals, Is Null, Is not Null, Is Empty, Is not Empty.

Date fields: Before, After, Before or Equals, After or Equals, Equals, Not Equals, Is Null, Is not Null, Is Empty, Is not Empty.

Select (dropdown/multi-select) fields: Is any of, Neither of.

Boolean fields: Equals, Not Equals.

When referencing Data Center values (rather than form fields), a broader set of operators is available that includes all of the above — giving maximum flexibility for dynamic values.

Comparing Two Dynamic Values

Both the operand (left side) and value (right side) of a rule can reference Data Center paths. This means you can compare two dynamic values against each other — for example, checking whether the requested leave end date is after the start date, or whether a computed budget exceeds a threshold stored in a global variable.

Output Handles

Every condition you add creates a corresponding named output handle on the Decision Node in the canvas. You connect each handle to the node that should execute when that condition is satisfied. There is always a Default handle that cannot be removed — it serves as the fallback path.

Each handle can have exactly one outgoing edge.

Progress Path

You can choose to hide the Decision Node from the workflow's visible progress tracker if it is skipped during execution.

---

How It Works at Runtime

1. Data is loaded — the system fetches all available Data Center values for the current workflow instance, including form submissions, node outputs, and system variables.
2. Conditions are evaluated in order — for each condition, all Data Center references in the operands and values are resolved to their actual runtime values, and the boolean expression is evaluated.
3. First match wins — if a condition evaluates to true, the workflow immediately follows that condition's output handle. All remaining conditions are skipped.
4. If no conditions match — the workflow follows the Default handle.
5. Non-matching branches are skipped — all nodes connected to non-matching condition handles (and their downstream sub-branches) are cleanly skipped without executing.

---

Validation Rules

The workflow builder validates Decision Nodes at publish time:

• The node must have exactly one incoming edge (no fan-in allowed).
• Every condition must have exactly one outgoing edge connected to its handle.
• The Default handle must have exactly one outgoing edge.
• No handle may have more than one outgoing edge.

If any of these rules are violated, the publish will fail with a descriptive error.

---

Best Practices

• Order conditions from most specific to most general. Since evaluation is short-circuit (first match wins), put narrow conditions before broad ones. The Default handle naturally acts as your "else" case.
• Use meaningful condition names. These names appear on the canvas as handle labels and in execution logs. Names like "High Priority (> $10K)" are far more useful than "Condition 1".
• Keep expressions simple. If a single condition requires more than 3–4 rule groups, consider splitting the logic across multiple Decision Nodes in series for readability.
• Always connect the Default handle. Even if you believe your conditions are exhaustive, the Default path prevents the workflow from silently dead-ending if unexpected data arrives.
• Prefer Data Center references over hardcoded values when the comparison target might change — for example, threshold amounts that could be updated without modifying the workflow.
• Test edge cases with null and empty checks. If a form field might not be filled, add an explicit Is Null or Is Empty condition, or handle it gracefully in the Default path.