Skip to main content

​
What Are Workflow Conditions?

Workflow conditions are decision-making nodes that evaluate data and create branching paths in your automation. Conditions enable intelligent workflows that respond dynamically to different data values, user inputs, and business scenarios. Key benefits of workflow conditions:
  • Create intelligent, responsive automations
  • Handle different scenarios with branching logic
  • Validate data before processing
  • Implement business rules and policies
  • Build sophisticated decision trees

​
How Workflow Conditions Create Smart Branching

All workflow conditions follow a consistent evaluation pattern:
  1. Input: Receive data from previous workflow steps
  2. Comparison: Apply operators like equals, contains, or greater-than
  3. Result: Generate true/false outcomes
  4. Routing: Direct workflow execution down different paths
This pattern enables sophisticated automation logic while maintaining simplicity.

​
Practical Condition Example

Here’s how condition-based branching works in a real workflow: You can connect the true and false output handles to different downstream actions, creating separate execution paths that respond intelligently to your data.

​
Complete Condition Types Reference

Select the right condition type for your data evaluation needs. Each condition type provides specialized operators optimized for specific data formats:

​
String Condition: Text and Status Evaluation

String conditions compare text values, making them essential for status checking, user input validation, and text-based business logic. Common use cases:
  • Check order status (“pending”, “completed”, “cancelled”)
  • Validate user roles and permissions
  • Filter content by category or tag
  • Process form input validation
  • Match text patterns with regex

​
Configuration

​
input
variable
required
A reference to the string value to check.
​
operator
string
required
The comparison to perform. Options: equals, not_equals, contains, not_contains, starts_with, ends_with, regex.
​
value
string
required
The value to compare against.
For the regex operator, you must provide a full, valid regular expression pattern including delimiters (e.g., /pattern/i).

​
Number Condition: Numeric Value Comparison

Number conditions evaluate numeric values including integers, decimals, and calculated amounts. Essential for financial calculations, quantity checking, and threshold-based automation. Common use cases:
  • Check order amounts and pricing thresholds
  • Validate inventory quantities
  • Process age and numeric user data
  • Implement scoring and rating systems
  • Monitor performance metrics

​
Configuration

​
input
variable
required
A reference to the number to check.
​
operator
string
required
The comparison to perform. Options: equals, not_equals, greater_than, less_than, greater_than_or_equal, less_than_or_equal.
​
value
number
required
The number to compare against.

​
Date Condition: Time-Based Logic and Scheduling

Date conditions evaluate dates and times for scheduling logic, deadline checking, and time-based business rules. Handle timezone considerations and relative date comparisons. Common use cases:
  • Check subscription expiration dates
  • Validate event scheduling conflicts
  • Process time-based promotions
  • Monitor deadline compliance
  • Handle timezone-aware comparisons

​
Configuration

​
input_date
string or variable
required
The date/time value to check.
​
operator
string
required
The comparison to perform. Options: is_past, is_future, is_today, is_weekend, is_weekday, is_before, is_after, is_same_day, is_within, is_not_within.
​
comparison_date
string or variable
Required for is_before, is_after, is_same_day.
​
value
integer
Required for is_within and is_not_within (e.g., 7).
​
unit
string
Required for is_within and is_not_within. Options: days, weeks, months, etc.

​
Boolean Condition: True/False Evaluation

Boolean conditions evaluate true/false values with intelligent handling of different truthiness representations. Automatically converts strings, numbers, and other data types to boolean values. Common use cases:
  • Check feature flags and settings
  • Validate user permissions and access
  • Process checkbox and toggle states
  • Handle API response success flags
  • Implement conditional feature logic

​
Configuration

​
input
variable
required
A reference to the value to check.
​
operator
string
required
The comparison to perform. Options: is_true, is_false.

​
Array Condition: List and Collection Processing

Array conditions evaluate lists and collections, enabling batch processing logic and list validation. Check array contents, sizes, and element properties for complex data handling. Common use cases:
  • Validate API response data arrays
  • Check if users exist in lists
  • Process bulk import validation
  • Handle shopping cart contents
  • Validate multi-select form inputs

​
Configuration

​
input_array
variable
required
A reference to the array to check.
​
operator
string
required
The comparison to perform. Options: is_empty, is_not_empty, count_equals, count_not_equals, count_greater_than, count_less_than, contains_value, does_not_contain_value, any_item_matches.
​
value
any
Required for count and contains checks.
​
conditions
array of conditions
Required only for any_item_matches. This allows you to define a set of conditions that will be tested against each item in the array. If any single item satisfies all the nested conditions, the node returns true.

​
Logical Group Condition: Complex Decision Logic

Logical Group conditions combine multiple conditions using AND/OR logic with support for nested groups. Build sophisticated business rules and complex decision trees in a single, maintainable node. Common use cases:
  • Complex eligibility rules (age AND location AND status)
  • Multi-criteria filtering and search
  • Advanced permission checking
  • Business rule validation
  • Sophisticated approval workflows

​
Configuration

This node has a nested structure. The top-level group defines the primary logic (AND or OR) and contains a list of rules. Each rule can be either a simple condition or another nested logical group.
​
logic
string
required
The logic for the group. Options: AND, OR.
​
rules
array
required
An array of rules. Each rule is an object that is either a Condition or another Logical Group.

​
Switch Condition: Multi-Path Routing

Switch conditions evaluate multiple condition sets in order, routing workflow execution to the first matching path. More efficient and maintainable than chains of individual condition nodes. Common use cases:
  • Customer segmentation routing
  • Priority-based task assignment
  • Multi-tier pricing logic
  • Content categorization workflows
  • Complex approval routing

​
Configuration

The Switch node is configured with a list of “cases”.
​
cases
array
required
An ordered list of cases to evaluate.

​
Behavior

  • The cases are evaluated from top to bottom.
  • The first case where all of its internal conditions are true is considered a match.
  • The workflow then proceeds down the path connected to that case’s unique handle.
  • If no cases match, the workflow proceeds down the default path.
⌘I