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:- Input: Receive data from previous workflow steps
- Comparison: Apply operators like equals, contains, or greater-than
- Result: Generate true/false outcomes
- Routing: Direct workflow execution down different paths
Practical Condition Example
Here’s how condition-based branching works in a real workflow: You can connect thetrue
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
A reference to the string value to check.
The comparison to perform.
Options:
equals
, not_equals
, contains
, not_contains
, starts_with
, ends_with
, regex
.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
A reference to the number to check.
The comparison to perform.
Options:
equals
, not_equals
, greater_than
, less_than
, greater_than_or_equal
, less_than_or_equal
.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
The date/time value to check.
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
.Required for
is_before
, is_after
, is_same_day
.Required for
is_within
and is_not_within
(e.g., 7
).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
A reference to the value to check.
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
A reference to the array to check.
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
.Required for count and contains checks.
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.
The logic for the group. Options:
AND
, OR
.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”.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.