Skip to main content

​
Purpose

The Condition node routes the workflow to different branches based on a condition. Evaluate data from previous nodes and take the appropriate path. Only one branch executes per condition evaluation. Condition nodes are the decision points in your workflows. They enable dynamic routing based on data, creating adaptive workflows that respond to different scenarios intelligently.

​
How conditions work

When execution reaches a Condition node:
1

Evaluate condition

The condition expression is evaluated using data from the variable store. The expression returns true or false.
2

Choose branch

  • If the condition evaluates to true → execute the “true” branch
  • If the condition evaluates to false → execute the “false” branch
3

Execute chosen branch

Only one branch executes. The other branch is skipped entirely.
4

Continue workflow

After the chosen branch completes, the workflow continues to the next node after the Condition node.
Condition nodes enable dynamic, adaptive workflows. The same workflow definition can handle different scenarios by routing through different branches based on runtime data.

​
Configuration

Configure a Condition node to evaluate the right condition and route to the right branches.

​
Condition expression

Define the condition using data from previous node outputs. Condition expressions support:
  • Variable references — Access any data in the variable store
  • Comparison operators — ==, !=, >, <, >=, <=
  • Logical operators — AND, OR, NOT
  • String operations — contains, startsWith, endsWith, matches
  • Numeric operations — Math operations, numeric comparisons
  • Existence checks — exists, isEmpty, isNull
Simple condition examples: 
// Numeric comparison
{{risk_agent.output.risk_score}} > 0.8

// String equality
{{document_agent.output.document_type}} == "passport"

// Boolean check
{{compliance_agent.output.requires_review}} == true

// Existence check
exists({{agent.output.extracted_data}})
Complex condition examples: 
// Multiple conditions with AND
{{risk_agent.output.risk_score}} > 0.7 AND {{financial_agent.output.amount}} > 50000

// Multiple conditions with OR
{{document_agent.output.document_type}} == "passport" OR {{document_agent.output.document_type}} == "emirates_id"

// Nested conditions
({{risk_score}} > 0.8 OR {{amount}} > 100000) AND {{requires_approval}} == true

// String contains
contains({{agent.output.analysis}}, "high risk")

​
True branch

Define the activities to execute when the condition is true. The true branch can contain any combination of node types:
  • Agent nodes
  • Tool nodes
  • Nested Condition nodes
  • Parallel nodes
  • Human Task nodes
Example true branch: High risk processing When risk score is high, route to human review: 
True Branch:
  → Human Task: "Review high-risk application"
  → Agent: "Document additional findings"
  → Tool: "Send escalation email"

​
False branch

Define the activities to execute when the condition is false. The false branch structure is identical to the true branch. Example false branch: Auto-processing When risk score is low, auto-process: 
False Branch:
  → Agent: "Generate approval letter"
  → Tool: "Update database status"
  → Tool: "Send approval email"

​
Multiple conditions (if-else-if chains)

Chain multiple Condition nodes to create if-else-if logic: 
Condition 1: risk_score > 0.9
  └─ True: Reject immediately
  └─ False: → Condition 2: risk_score > 0.7
      └─ True: Human review required
      └─ False: → Condition 3: risk_score > 0.4
          └─ True: Auto-approve with monitoring
          └─ False: Auto-approve

​
Condition syntax reference

​
Variable references

Access data from the variable store using double curly braces: 
{{trigger.input.customer_id}}
{{agent_name.output.field_name}}
{{tool_name.output.response.nested_field}}
Accessing nested fields: 
{{compliance_agent.output.analysis.risk_assessment.score}}
Accessing array elements: 
{{document_agent.output.findings[0].severity}}

​
Comparison operators

Equal to: ==
{{status}} == "approved"
{{count}} == 5
Not equal to: !=
{{status}} != "rejected"
{{score}} != 0

​
Existence checks

Check if variables exist or have values: 
// Check if variable exists
exists({{agent.output.optional_field}})

// Check if variable is empty
isEmpty({{agent.output.findings}})

// Check if variable is null
isNull({{agent.output.result}})

// Check if variable is defined (not null and not empty)
isDefined({{agent.output.data}})

​
Examples

Let’s look at practical examples of Condition nodes in real workflows.

​
Example 1: Confidence-based routing

Scenario: Route documents to auto-processing or human review based on confidence score. Condition: 
{{document_agent.output.confidence_score}} > 0.85
True branch (high confidence): 
Auto-processing:
  → Agent: "Validate extracted data"
  → Tool: "Update database"
  → Tool: "Send confirmation email"
False branch (low confidence): 
Human review:
  → Human Task: "Review extracted data"
  → Agent: "Process with human corrections"
  → Tool: "Update database"
  → Tool: "Send confirmation email"
Result: High-confidence documents are auto-processed, saving time. Low-confidence documents get human review, ensuring accuracy.

​
Example 2: Document type routing

Scenario: Route to different processors based on document type. Condition: 
{{document_classifier.output.document_type}} == "passport"
True branch (passport processing): 
Passport workflow:
  → Agent: "Extract passport data with passport-specific model"
  → Tool: "Validate passport number format"
  → Agent: "Check passport expiry date"
  → Tool: "Store passport data"
False branch (other documents): 
Generic document workflow:
  → Agent: "Extract data with generic model"
  → Tool: "Store document data"

​
Example 3: Risk-based escalation

Scenario: Escalate high-risk applications to management, auto-process low-risk. Multi-level condition chain: 
Condition 1: {{risk_score}} > 0.9
  ├─ True: REJECT
  │   → Agent: "Generate rejection letter"
  │   → Tool: "Send rejection email"
  │   → Tool: "Update database: rejected"
  │
  └─ False: Condition 2: {{risk_score}} > 0.7
      ├─ True: ESCALATE
      │   → Human Task: "Manager review required"
      │   → Agent: "Process based on manager decision"
      │   → Tool: "Send decision email"
      │
      └─ False: Condition 3: {{risk_score}} > 0.4
          ├─ True: AUTO-APPROVE with monitoring
          │   → Agent: "Generate approval letter"
          │   → Tool: "Set monitoring flag"
          │   → Tool: "Send approval email"
          │
          └─ False: AUTO-APPROVE
              → Agent: "Generate approval letter"
              → Tool: "Send approval email"
Result: Applications are routed to the appropriate approval path based on risk level, balancing automation with oversight.

​
Example 4: Business hours routing

Scenario: Different handling based on whether request arrives during business hours. Condition: 
{{trigger.received_hour}} >= 9 AND {{trigger.received_hour}} < 17 AND {{trigger.received_weekday}} != "Saturday" AND {{trigger.received_weekday}} != "Sunday"
True branch (business hours): 
Immediate processing:
  → Agent: "Process request"
  → Tool: "Assign to available team member"
  → Tool: "Send immediate response"
False branch (after hours): 
Queued processing:
  → Tool: "Add to queue"
  → Tool: "Send auto-reply: Will process during business hours"
  → (Schedule for next business day)

​
Example 5: Multi-factor approval routing

Scenario: Require different approval levels based on amount and department. Condition: 
{{transaction.amount}} > 100000 AND {{transaction.department}} == "finance"
True branch (high-value finance): 
CFO approval required:
  → Human Task: "CFO review and approval"
  → Condition: {{approval.cfo_approved}} == true
      ├─ True: Process transaction
      └─ False: Reject and notify
False branch (standard processing): 
Manager approval sufficient:
  → Human Task: "Manager review"
  → Condition: {{approval.manager_approved}} == true
      ├─ True: Process transaction
      └─ False: Reject and notify

​
Advanced patterns

​
Condition with fallback

Add error handling within conditional branches: 
Condition: {{risk_score}} > 0.8
  ├─ True: High-risk processing
  │   → Agent: "Detailed analysis"
  │   → Condition: {{agent.execution_successful}} == true
  │       ├─ True: Continue
  │       └─ False: → Human Task: "Manual review"
  │
  └─ False: Standard processing
      → Agent: "Standard analysis"

​
Nested conditions for complex logic

Create sophisticated decision trees: 
Condition: {{document_type}} == "invoice"
  ├─ True: Invoice processing
  │   → Condition: {{invoice.amount}} > 50000
  │       ├─ True: High-value invoice
  │       │   → Condition: {{vendor.is_approved}} == true
  │       │       ├─ True: Auto-process
  │       │       └─ False: Vendor verification required
  │       │
  │       └─ False: Standard invoice
  │           → Auto-process
  │
  └─ False: Non-invoice processing
      → Generic document workflow

​
Condition with parallel branches

Combine conditions with parallel execution: 
Condition: {{requires_multi_agent_analysis}} == true
  ├─ True: Parallel multi-agent analysis
  │   → Parallel Node
  │       ├─ Branch 1: Technical agent
  │       ├─ Branch 2: Financial agent
  │       └─ Branch 3: Legal agent
  │   → Synthesis agent
  │
  └─ False: Single agent analysis
      → General-purpose agent

​
Best practices

Complex conditions are hard to debug. Break complex logic into multiple Condition nodes rather than one giant expression.Good: Chain of simple conditions Poor: ((A > 5 AND B < 10) OR (C == "value" AND D != "other")) AND NOT (E > 100 OR F < 0)
Always check that variables exist before using them in conditions. Use exists() or isDefined() checks.
exists({{agent.output.score}}) AND {{agent.output.score}} > 0.8
Name branches based on what they do, not just “true” and “false”. Good names: “High risk processing” vs “Standard processing”.
In the visual editor, add notes explaining what complex conditions check for. Future you will appreciate it.
Always test workflows with data that triggers both the true and false branches. Don’t just test the happy path.
Condition nodes implement business rules in a visible, maintainable way. Don’t hide business logic inside agent prompts.
If a condition might fail to evaluate (due to missing data), add a fallback path that handles the error gracefully.
Combine Condition nodes with Human Task nodes for approval workflows. Route high-risk items to human review while auto-processing low-risk items. This balances automation with human oversight.

​
Common patterns

​
Approval workflows

Condition: {{amount}} > 10000
  ├─ True: Requires approval
  │   → Human Task: "Manager approval"
  │   → Condition: {{approval.approved}} == true
  │       ├─ True: Process transaction
  │       └─ False: Reject transaction
  │
  └─ False: Auto-approve
      → Process transaction

​
Quality assurance

Condition: {{quality_score}} >= 0.9
  ├─ True: High quality
  │   → Auto-publish
  │
  └─ False: Needs review
      → Human Task: "Quality review"
      → Condition: {{review.approved}} == true
          ├─ True: Publish with notes
          └─ False: Request revision

​
Exception handling

Condition: {{agent.execution_successful}} == true
  ├─ True: Continue workflow
  │   → Next activity
  │
  └─ False: Error handling
      → Tool: "Log error"
      → Human Task: "Manual intervention"

​
Data validation

Condition: isDefined({{required_field}}) AND {{required_field}} != ""
  ├─ True: Valid data
  │   → Continue processing
  │
  └─ False: Invalid data
      → Tool: "Send error notification"
      → Agent: "Generate error report"

​
Next steps

Human task node

Add human approval in conditional branches

Parallel node

Combine conditions with parallel execution

Memory system

Understand how to access data for conditions

Agent node

Use agent outputs as condition inputs