Skip to main content

​
Overview

The Condition Node evaluates expressions against workflow context variables and routes execution to different branches based on the results. It is the primary mechanism for adding if/else logic to your workflows, enabling dynamic behavior that adapts to user input, LLM output, or any other runtime data. Each Condition Node supports multiple branches with independent evaluation rules, plus a default fallback branch for cases where no condition matches.

​
Configuration

{
  "type": "condition-node",
  "config": {
    "branches": [
      {
        "name": "high_confidence",
        "conditions": [
          {
            "variable": "{{confidence_score}}",
            "operator": "gte",
            "value": 0.8
          }
        ]
      },
      {
        "name": "needs_review",
        "conditions": [
          {
            "variable": "{{confidence_score}}",
            "operator": "gte",
            "value": 0.5
          },
          {
            "variable": "{{confidence_score}}",
            "operator": "lt",
            "value": 0.8
          }
        ]
      }
    ],
    "default_output": "fallback"
  }
}
ParameterTypeDescription
branchesConditionNodeBranch[]Ordered list of branches to evaluate
branches[].namestringBranch identifier, used as the output handle name
branches[].conditionsarrayList of conditions that must ALL be true for this branch (AND logic)
default_outputstringName of the default branch when no conditions match

​
Branch Evaluation

Branches are evaluated in order, top to bottom. The first branch whose conditions all evaluate to true is selected, and execution continues along that branch’s output edge. If no branch matches, the default_output branch is used.

​
Evaluation Order

Because evaluation is ordered, place more specific conditions before general ones. A broad condition early in the list will prevent narrower conditions below it from ever being reached.

​
Comparison Operators

The Condition Node supports a comprehensive set of comparison operators:

​
Value Comparisons

OperatorDescriptionExample
eqEqual to{{status}} eq "active"
neqNot equal to{{status}} neq "deleted"
gtGreater than{{score}} gt 90
gteGreater than or equal to{{score}} gte 80
ltLess than{{count}} lt 10
lteLess than or equal to{{count}} lte 100

​
String Operators

OperatorDescriptionExample
containsString contains substring{{message}} contains "urgent"
not_containsString does not contain substring{{message}} not_contains "spam"
starts_withString starts with prefix{{email}} starts_with "admin"
ends_withString ends with suffix{{file}} ends_with ".pdf"
regexMatches regular expression{{input}} regex "^[0-9]{3}-[0-9]{4}$"

​
Existence Operators

OperatorDescriptionExample
is_emptyValue is null, undefined, or empty string{{notes}} is_empty
is_not_emptyValue exists and is non-empty{{user_id}} is_not_empty
inValue is in a list{{lang}} in ["en", "ko", "ja"]
not_inValue is not in a list{{role}} not_in ["banned", "suspended"]

​
Multiple Conditions (AND Logic)

When a branch has multiple conditions, all conditions must be true for the branch to match. This provides AND logic within a single branch. 
{
  "name": "premium_active",
  "conditions": [
    {
      "variable": "{{plan}}",
      "operator": "eq",
      "value": "premium"
    },
    {
      "variable": "{{status}}",
      "operator": "eq",
      "value": "active"
    },
    {
      "variable": "{{days_remaining}}",
      "operator": "gt",
      "value": 0
    }
  ]
}
This branch matches only when the user’s plan is “premium” AND status is “active” AND they have remaining days.
For OR logic, create separate branches for each alternative condition. Since branches are evaluated independently, any matching branch will be selected.

​
Custom Expressions

For complex conditions that cannot be expressed with simple operators, use the expression type to write custom evaluation logic: 
{
  "name": "complex_check",
  "conditions": [
    {
      "type": "expression",
      "expression": "len({{search_results}}) > 0 and {{confidence_score}} >= 0.7"
    }
  ]
}
Custom expressions support basic arithmetic, string operations, list operations (len, in), and boolean combinators (and, or, not).

​
Output Handles

Each branch in the Condition Node creates a separate output handle in the visual editor. You connect different downstream nodes to each handle to define the execution path for each condition. In the visual editor, the output handles appear as labeled connection points on the right side of the node. Drag edges from each handle to the appropriate downstream node.

​
Example: Language Router

Route user messages to different AI Agent nodes based on detected language: 
{
  "type": "condition-node",
  "config": {
    "branches": [
      {
        "name": "korean",
        "conditions": [
          {
            "variable": "{{detected_language}}",
            "operator": "eq",
            "value": "ko"
          }
        ]
      },
      {
        "name": "japanese",
        "conditions": [
          {
            "variable": "{{detected_language}}",
            "operator": "eq",
            "value": "ja"
          }
        ]
      },
      {
        "name": "english",
        "conditions": [
          {
            "variable": "{{detected_language}}",
            "operator": "in",
            "value": ["en", "en-US", "en-GB"]
          }
        ]
      }
    ],
    "default_output": "english"
  }
}

​
Best Practices

Even if you think all cases are covered, include a default_output branch. Unexpected values or edge cases will route to the default instead of causing a workflow failure.
Since branches are evaluated in order, put narrow conditions first. A catch-all condition at the top will shadow everything below it.
Instead of writing complex expressions inside condition branches, use a Variable Node upstream to compute a simple boolean or category value, then branch on that value in the Condition Node.
Workflows with more than 5-6 branches on a single Condition Node become hard to follow. Consider chaining multiple Condition Nodes or using an Intent Classifier for many-way routing.

​
Next Steps

Intent Classifier

AI-powered routing for natural language intent detection

Start & End Nodes

Configure the entry and exit points of your workflow

Loop Node

Iterate over collections with conditional exit

AI Agent Node

Process branched inputs with LLM reasoning