Configure Conditions
Branch a workflow based on record data.
Conditions let a workflow take different paths depending on whether rules match.
Use conditions when the next step should depend on trigger data, record fields, or records created by earlier actions.
Use conditions to protect actions from running on the wrong records. A good condition is often the difference between a helpful automation and noisy automation that creates cleanup work.
Write the business rule in plain language before configuring operators. This helps avoid conditions that are technically valid but operationally wrong.
For example, write "only notify finance when invoice amount is greater than 5000 and status is unpaid" before selecting fields and operators.
Add A Condition
- Open the workflow builder.
- Add a Condition node from flow control.
- Configure the condition rules.
- Connect the true branch to the steps that should run when the condition matches.
- Connect the false branch to the steps that should run when it does not match.
Filter Modes
Conditions support a simple list mode and a grouped logic mode. Simple list evaluates rules as AND. Grouped mode lets you choose AND or OR for the group.
Common field examples include contact.status, contact.email,
account.name, deal.stage, deal.value, task.priority, source, and
value.
Use grouped logic when the rule needs a mix of AND and OR conditions. Keep the group names or surrounding action labels clear so future editors understand why the branch exists.
Operators
Supported operators include equals, not equals, contains, not contains, starts with, ends with, greater than, less than, greater than or equal, less than or equal, in, not in, includes any, includes all, is empty, and is not empty.
Operators such as is empty and is not empty do not need a value. Operators such as in, not in, includes any, and includes all accept comma separated values.
Review Branch Connections
The builder shows whether the true and false branches are connected. A condition without a connected branch may skip work you expected to run.
If the false branch should intentionally do nothing, document that in the workflow name, node label, or nearby action label where possible. Silent false branches are hard to distinguish from unfinished automation.
Test Conditions
Run test data for both branches. A condition that only works for the happy path can silently skip important work when the false branch is missing or configured incorrectly.
Troubleshooting
If the wrong branch runs, open run detail and compare the actual field value with the condition value.
If a condition is always false, check variable availability, spelling, empty values, data type, and whether the selected node runs before the data exists.
If a condition uses imported, synced, or optional data, test records where that field is missing. Empty values often behave differently from values that simply do not match.
Branch Review
Before publishing:
- Test the true branch.
- Test the false branch.
- Confirm blank values behave correctly.
- Confirm the condition uses data that exists before the node runs.
- Add a clear label or nearby note when an empty false branch is intentional.
Keep Conditions Readable
Use one condition for one decision whenever possible. If the workflow needs many nested conditions, split the process into smaller workflows or add clear labels so future reviewers can understand why each branch exists.
When a condition protects a customer-facing action, test the record that should send the action and the record that must not send it.