Skip to main content

​
Logic Components

Logic components control the flow of your automation by routing data based on conditions. They allow you to create branching paths where different actions are taken depending on your data.

​
How Logic Components Work

Logic components evaluate conditions and output data to one of two paths: 
              ┌─── True Output ──→ Path A
Input ──→ Condition
              └─── False Output ─→ Path B
  • True Output: Data flows here when the condition is met
  • False Output: Data flows here when the condition is not met
You can leave either output unconnected if you only need one path. For example, only send an alert when a condition is true, and do nothing otherwise.

​
If-Else V2

Routes data based on text/string comparisons.

​
Configuration

FieldDescription
Input TextThe text value to evaluate (supports @ notation)
OperatorComparison operation
Match ValueValue to compare against
Case SensitiveWhether comparison is case-sensitive (default: false)
Max IterationsMaximum times this node can execute in a loop (default: 100)

​
Operators

OperatorDescriptionExample
equalsExact match"Active" equals "Active" → True
not equalsDoes not match"Active" not equals "Churned" → True
containsContains substring"Hello World" contains "World" → True
starts withBegins with string"Enterprise Plan" starts with "Enterprise" → True
ends withEnds with string"user@acme.com" ends with "acme.com" → True
regexMatches regular expression"ABC-123" regex "^[A-Z]+-\d+$" → True

​
Example: Route by Account Status

Configuration:
  • Input Text: @account_data.status
  • Operator: equals
  • Match Value: Active
Result:
  • Active accounts → True Output
  • All other accounts → False Output

​
Example: Email Domain Check

Configuration:
  • Input Text: @contact_email
  • Operator: ends with
  • Match Value: @competitor.com
  • Case Sensitive: false
Result:
  • Competitor emails → True Output (maybe skip)
  • Other emails → False Output (proceed)

​
Condition V2

Routes data based on conditions evaluated against specific data fields.

​
Configuration

FieldDescription
FieldThe data field to evaluate (use @ notation)
OperatorComparison operation
ValueValue to compare against
Max IterationsMaximum loop iterations (default: 100)

​
Operators

OperatorDescriptionExample
equalsExact match (works with numbers and strings)@health_score equals 100
not equalsDoes not match@status not equals "Churned"
greater thanNumeric comparison, true if field > value@arr greater than 100000
less thanNumeric comparison, true if field < value@health_score less than 50
greater than or equalNumeric comparison, true if field ≥ value@mrr greater than or equal 10000
less than or equalNumeric comparison, true if field ≤ value@days_to_renewal less than or equal 30
containsFor strings, checks substring; for arrays, checks membership@tags contains "enterprise"
starts withString begins with value@name starts with "Acme"
ends withString ends with value@domain ends with ".edu"
boolean validatorChecks truthiness of a value@is_champion boolean validator

​
Example: High-Value Account Filter

Configuration:
  • Field: @account_data.arr
  • Operator: greater than
  • Value: 100000
Result:
  • Accounts with ARR > $100K → True Output
  • Accounts with ARR ≤ $100K → False Output

​
Example: Champion Status Check

Configuration:
  • Field: @contact_data.is_champion
  • Operator: boolean validator
  • Value: true
Result:
  • Champions → True Output
  • Non-champions → False Output

​
Iteration Tracking

Both logic components track how many times they’ve executed within a single flow run. This prevents infinite loops when your flow has cycles.

​
How It Works

  1. Each execution increments the iteration counter
  2. When max_iterations is reached, the component outputs to a default path
  3. The counter resets at the start of each new flow run

​
Configuration

FieldDescription
Max IterationsMaximum executions before forcing default output (default: 100)
If you’re hitting max iterations unexpectedly, check your flow for unintended loops or recursive patterns.

​
Common Patterns

​
Pattern: Multiple Conditions

Chain conditions for complex logic: 
┌─────────┐     ┌─────────┐     ┌─────────┐
│ ARR>100K│──T─▶│ Active? │──T─▶│ Action  │
└─────────┘     └─────────┘     └─────────┘
     │               │
     F               F
     ▼               ▼
  (skip)          (skip)

​
Pattern: Multi-Way Routing

Use multiple conditions to create several paths: 
             ┌─── Status=Active ──▶ Path A
             │
Input ──────▶┼─── Status=AtRisk ──▶ Path B
             │
             └─── Otherwise ──────▶ Path C
Implementation:
  1. First If-Else: Check for “Active” → True goes to Path A
  2. Second If-Else (on False output): Check for “At Risk” → True goes to Path B, False goes to Path C

​
Pattern: Null/Empty Check

Check if a field has a value before using it: Configuration:
  • Field: @account_data.owner_email
  • Operator: not equals
  • Value: “ (empty string)
This routes to True if the owner email exists, False if empty.

​
Pattern: Numeric Ranges

For range checks, chain two conditions: 
┌─────────────┐     ┌──────────────┐
│ Score >= 50 │──T─▶│ Score < 80   │──T─▶ "Medium" path
└─────────────┘     └──────────────┘
       │                   │
       F                   F
       ▼                   ▼
   "Low" path         "High" path

​
Best Practices

Begin with straightforward true/false logic. Add complexity only when needed.
Rename condition nodes to describe what they check: “Is High Value?” or “Has Champion Contact?”
Even if you only care about one outcome, consider what should happen on the other path. At minimum, add logging.
Test your conditions with:
  • Empty/null values
  • Boundary values (exactly 100K when checking > 100K)
  • Different data types (string “100” vs number 100)
For multi-condition flows, add comments or descriptions explaining the overall logic.

​
Troubleshooting

  • Check that the field path is correct (use @ notation)
  • Verify the data type matches (string vs number)
  • Test the node individually to see the actual input values
  • Check case sensitivity settings
  • Empty strings may evaluate differently than expected
  • Check for whitespace in string comparisons
  • Verify the operator matches your intent
  • Look for loops in your flow
  • Check if a condition is always routing back to itself
  • Increase max_iterations if the loop is intentional and bounded

​
Next Steps

Processing Components

Transform data before conditions

Testing Flows

Test your conditional logic