If/Then Automation
If/then automation is conditional logic that runs an action only when a specified condition is true, letting CRM and marketing tools respond differently to leads based on their data or behavior.
Key takeaways
- A rule evaluates a snapshot, so later field changes do not reroute anyone.
- An explicit else branch guarantees every record matches at least one path.
- Overlapping ranges let one record match two branches and receive conflicting messages.
- Empty fields satisfy neither greater-than nor less-than comparisons and fall through.
- Branch on a named tier rather than a raw number so thresholds stay editable.
In depth
An if/then rule is a boolean expression evaluated at a specific moment against a specific record. The expression combines comparisons with AND, OR and NOT, and the platform walks the branches in a defined order, taking the first that returns true. Evaluation is a snapshot rather than a subscription: the branch is chosen from the values present at that instant, and a field that changes a minute later does not move the contact. Null values are the quiet complication, because an empty field is neither above nor below a threshold.
Two properties matter above all: coverage and exclusivity. Coverage means every record matches at least one branch, which an explicit else branch guarantees. Exclusivity means no record matches two, which overlapping ranges quietly break, since score above sixty and score above eighty both catch a ninety. Deeper nesting buys precision at the cost of readability, and each added condition cuts the number of records reaching the deepest branch, so a five-level tree usually contains paths nobody has ever taken.
In practice you write branch conditions as ranges that touch but never overlap, and you place the narrowest condition first if the tool evaluates in order. Scorecard tiers make good branch boundaries because they already partition the score space: a rule reading tier equals hot, rather than score above eighty, stays correct when somebody edits the threshold later. Combining a firmographic filter with a score condition, such as industry plus tier, is where routing rules usually earn their keep.
If/then logic is a decision, not a state machine, so it cannot express waiting or sequencing on its own; a delay node has to sit between two rules. It also encodes assumptions that outlive the data, since a branch keyed on a field that stops being populated silently routes everyone to the else path. And a rule tree cannot weigh evidence. When you find yourself writing eight conditions to approximate degrees of fit, what you actually want is a score with one threshold.
Example in practice
How to measure it
Count records per branch and compare against what you expected. A branch receiving almost nothing usually holds an unreachable condition, and a branch receiving nearly everything is doing no filtering at all. Put a counter on the else path specifically, because a growing else count is the earliest signal that an upstream field stopped being populated or that a new value appeared which the rule never anticipated.
Then measure outcome differences between branches. If contacts routed to the hot branch convert at roughly the rate of those on the warm branch, the condition separating them is not discriminating and the split adds complexity for nothing. Track this per boundary rather than per workflow, because usually one threshold does the real work while the others are decoration.
Common mistakes
The classic error is writing conditions that leave a gap. A rule handles scores above eighty and below fifty, everyone in between silently receives nothing, and it shows up later as an unexplained drop in follow-up. Build the branches as a partition: draw the boundaries on paper, check that every value from the minimum to the maximum lands somewhere, and add an else branch routing leftovers to a review list rather than to nothing.
The second error is mixing AND and OR without brackets. Industry equals healthcare AND score above sixty OR industry equals finance reads very differently depending on how the tool groups the terms, and most builders never show the grouping. Split compound conditions into nested rules where the platform allows it, and test each combination with a record built for it, including the cases you expect to be excluded.
Frequently asked questions
Is if/then automation the same as an automation workflow?
No. If/then logic is the conditional decision point, while a workflow is the broader sequence that may contain many if/then branches. You use if/then rules as the building blocks inside a workflow.
Can I nest multiple if/then conditions?
Yes, most platforms let you combine conditions with AND/OR operators or stack branches inside branches. Keep nesting shallow and well-labeled so the logic stays readable and testable.
What happens if no condition matches a lead?
Most tools let you define a default or "else" branch that catches contacts no rule matched. Always set one so leads are never stranded without a next step.
What is the difference between if/then logic and a workflow?
If/then logic is the decision made at one node; a workflow is the whole path, including timing and actions. You can have a workflow with no conditional logic at all, and you can evaluate a rule outside any workflow, for instance when assigning an owner on record creation. Keeping the distinction clear tells you whether a problem is bad routing or bad sequencing.
How do I handle empty fields in a condition?
Test for the empty case explicitly, before the comparisons. A blank score is neither above nor below a threshold, so it falls through every numeric branch and lands in the else path or nowhere at all. Add a first branch catching records that are missing the field and send them to enrichment or a review queue, rather than letting them silently disappear.
Should I use nested rules or several separate rules?
Nest when the conditions are genuinely dependent, and separate them when they are not. A nested tree keeps related decisions in one place but becomes unreadable past three levels. Independent decisions, such as assigning a language and assigning an owner, belong in separate rules, because combining them creates a branch for every combination and most will never be used.
How do I test if/then branches before launch?
Build one test record per branch, including boundary values sitting exactly on each threshold and one record with the field left empty. Run them through and check where each landed. Boundary values matter most, because the difference between greater-than and greater-than-or-equal decides whether the record on the line falls into the tier above or the one below.
Why do some contacts match two branches?
Because the conditions overlap, usually where ranges were written independently rather than as a partition. If the tool takes the first true branch, the second is dead code; if it runs every matching branch, the contact receives both treatments. Rewrite the ranges so each has a lower and an upper bound, and never leave two branches open-ended at the same end.
When should I replace rules with scoring?
When the number of conditions grows past what you can explain in a sentence, or when conditions start expressing degree rather than fact. Rules answer yes or no well and approximate how good a fit is badly. Convert the many weak conditions into points, keep one or two hard rules as filters, and branch on the resulting score band instead.