Switch Node
The Switch Node routes workflow execution to different paths based on multiple rules with conditions. It evaluates rules in sequential order until the first match is found, then outputs that rule's value for downstream routing decisions. When no rules match, a configurable default output provides a fallback path.
How It Works
The Switch node evaluates multiple rules in sequential order to produce a routing decision that determines which downstream path the workflow follows. Each rule contains one or more conditions evaluated against workflow data, similar to a multi-way if-else statement. When the node executes, it retrieves values from workflow variables using data field paths that support dot notation for nested objects and bracket notation for array access.
Rules follow first-match-wins logic: as soon as a rule's conditions evaluate to true, the node outputs that rule's specified value and stops evaluating remaining rules. This allows prioritization by placing more specific conditions before general ones. Within each rule, multiple conditions can be combined using AND (all must be true) or OR (at least one must be true) logical operators, with short-circuit evaluation for performance optimization.
If no rules match, the node outputs the configured default value as a fallback. The output value (either from a matched rule or the default) is stored in a workflow variable (defaulting to routing_decision) and determines which downstream node executes next. The value field in conditions supports variable interpolation using ${variable_name} syntax, enabling dynamic comparisons where values come from other workflow variables.
Configuration Parameters
Switch Rules
Switch Rules (Array, Required): Rules evaluated in order. At least one rule is required.
Rules determine routing decisions and are evaluated in sequential order. The first rule whose conditions evaluate to true determines the output value. Remaining rules are not evaluated after a match is found. More specific conditions should be placed before general ones to ensure correct routing logic.
Each rule has the following properties:
Conditions (Array, Required): List of conditions to evaluate. At least one condition is required. When multiple conditions exist in a rule, they combine using the Logical Operator (AND or OR).
Logical Operator (Dropdown, Default: AND): How to combine multiple conditions within the rule.
| Operator | Behavior | Use when |
|---|---|---|
| AND (default) | All conditions must be true | All criteria must be met simultaneously |
| OR | At least one condition must be true | Any criterion can trigger this path |
Short-circuit evaluation optimizes performance: AND stops at the first false condition, OR stops at the first true condition.
Output (Text, Required): Output value if this rule matches, used for routing. This value determines which downstream path executes. Descriptive values that clearly indicate the routing destination improve workflow readability.
Common patterns: premium_user, basic_flow, error_handling, high_priority, 0, 1, 2
Condition Properties
Each condition within a rule specifies how to evaluate workflow data:
Data Field (Text, Required): Workflow variable to evaluate. Supports dot notation for object properties (user.profile.age), bracket notation for array elements (results[0].score), or combinations (items[2].metadata.status).
Data Type (Dropdown, Default: String): Data type of the field being evaluated.
| Data type | Comparison Behavior | Notes |
|---|---|---|
| String (default) | Pattern matching and case sensitivity | Lexicographic comparison: "10" > "2" is false |
| Number | Mathematical operations | Numeric comparison: 10 > 2 is true |
| Boolean | Truthy/falsy values | Handles true/false evaluation |
| Date | Chronological comparisons | Works with timestamps; best with ISO 8601 format |
| Array | Size or content evaluation | Compares array length or checks item presence |
| Object | Property existence checks | Verifies if properties exist in objects |
Operator (Dropdown, Required): Comparison operator based on the selected data type. String operators support pattern matching, number operators perform mathematical comparisons, array operators evaluate both size and content, and object operators check property existence. Operators like Is Empty, Is Not Empty, Is True, and Is False do not require a comparison value.
Value (Text, Conditional): Comparison value. Supports variable interpolation with ${variable_name} for dynamic comparisons. Not required for Is Empty, Is Not Empty, Is True, Is False operators.
Case Sensitive (Toggle, Default: OFF): Enables case-sensitive string comparisons. When enabled, "Premium" and "premium" are different values. Only available for String data type.
Strict Type Validation (Toggle, Default: OFF): Prevents automatic type conversion between strings and numbers. With strict validation, "10" and 10 are treated as different values.
Default Output
Default Output (Text, Default: "default"): Output value when no rules match.
The default output provides a fallback routing decision ensuring the workflow always has a valid routing path. The default output should represent a safe or expected fallback path.
Common patterns: default, fallback, unknown, standard_flow, 3
Common Parameters
This node supports common parameters shared across workflow nodes, including Logging Mode and Wait For All Edges. For detailed information, see Common Parameters.
Best Practices
- Order rules from most specific to most general, as the first matching rule determines the output
- Descriptive output values that clearly indicate routing destinations improve workflow maintainability
- Enable Strict Type Validation when working with external data sources to prevent unexpected results from automatic type conversion
- Variable interpolation in the Value field creates dynamic routing logic that adapts based on workflow context
- Keep conditions per rule manageable; complex rules with many conditions can be broken into multiple simpler rules
Limitations
- First-match-wins evaluation: Rules are evaluated in order, and evaluation stops at the first match. Subsequent rules are not evaluated even if they would also match.
- Sequential processing: Rules are evaluated sequentially, not in parallel. Workflows with many rules may experience performance impact from evaluating multiple complex conditions.
- Output value type: Output values are always strings. Numeric or boolean routing values require string representations (e.g., "0", "1", "true", "false").