Condition steps and branching

What it does

Condition steps split a sequence into a Yes path and a No path based on what the customer did, what the record says, or where the business process flow has got to. They're what turns a fixed call list into something that reacts, and they're also where most sequence builds go wrong.

Key facts

Every condition produces exactly two branches, Yes and No. There is no third path and no default fall-through.
Email conditions cover Email open, Recipient reply, Link opened and Attachment downloaded, plus an advanced mode that combines several of these using All of them (every selected action must happen) or One of them (any single one is enough).
Email conditions take a time limit in days and hours. There's a checkbox to move straight to the Yes path as soon as the action happens rather than waiting out the full window — without it, the sequence sits and waits.
Phone call conditions branch on call outcome. Advanced mode offers Made and Received, plus whatever custom status reasons an administrator has configured on the phone call activity.
If a seller skips a phone call step that has a condition on it, the sequence takes the No path.
Field conditions work against standard and custom fields on the record type, and against related entity fields. Lookup fields only appear in advanced mode, which also supports row conditions and grouped AND/OR logic rather than a single equals check.
Business process stage conditions branch on which BPF the record is on and which stage it's in. Multiple stages can be selected and are treated as OR.
All of this depends on a Power Automate flow: Sales Insights Adaptive sequence timeout flow. It handles the waiting and moves records on. If it's off, or its connection references aren't healthy, conditions stall.
Email conditions additionally need email engagement configured, and the sequence's email steps enabled for tracking.
You can't delete a step that is immediately followed by a condition. Remove the condition first.

When to use / skip

Conditions are the difference between a sequence people follow and a sequence people resent, so don't skip them entirely. But there's a strong argument for keeping the first version of any cadence linear and adding branching once the client has actually run it for a month. Branching invented in a workshop is almost always wrong, because nobody knows yet what proportion of leads reply, and the No path gets designed as an afterthought.

Field and BPF conditions are the safest to commit to early — they read data the organisation already trusts. Email conditions are the most seductive and the most fragile: they depend on tracking pixels and link rewriting, which means corporate mail scanners can register an "open" nobody performed, and a customer reading in plain text registers nothing at all. Treat open-based branching as a soft signal and reply-based branching as the reliable one.

Phone call conditions are worth it only if the client has a real, enforced set of status reasons on the phone call activity. If sellers close calls with whatever's top of the list, the branching is decorative.

Configuration decisions

Which signal each branch actually uses — reply versus open versus link click — and how much you're willing to trust the weaker ones.
The time limit on every email condition, and whether to tick the option that advances early. Getting this wrong makes sequences feel either frantic or dead.
Whether the No path is a genuine alternative path or just a longer wait before the same next step. Both are valid; deciding by accident is not.
Which phone call status reasons exist and are mandatory, since condition branching inherits whatever that option set contains.
Whether to branch on BPF stage or on a field. BPF stage is more readable in the designer; a field is more stable if the process flow is still being redesigned.
How deep to nest. There's no documented depth limit, but there's a practical one — roughly the point at which nobody but you can explain the canvas.

Gotchas

The Sales Insights Adaptive sequence timeout flow is the single point of failure for every condition in the environment. It gets turned off by solution imports, by environment copies, and by well-meaning admins tidying up flows. Check its connection references show as connected after every deployment.
A field condition against a field that doesn't exist on the connected record throws an error at runtime, not at design time. This bites when a sequence is cloned onto a different record type.
Skipped phone calls take the No path. Sellers who skip steps to clear their list are effectively voting on the branch, and nobody tells them that.
Email opens are unreliable in both directions — inflated by security scanners, missing entirely for plain-text readers. Building a "not interested" branch off a failed open produces bad decisions confidently.
Conditions can't be deleted independently of their surroundings in the way people expect. Restructuring a branched canvas is fiddly enough that cloning and rebuilding is often quicker.
Without email engagement configured, email conditions look configurable in the designer and simply never fire in the wild.

Consultant notes

Put the Adaptive sequence timeout flow on the go-live checklist and the post-deployment smoke test. It is the first thing to check whenever a client says "sequences have stopped moving".
Demo a branch with the No path, not the Yes path. Clients design for the happy case; showing them what happens when the customer ignores the email is where the useful requirements come out.
Push back on open-based branching for anything that has commercial consequences. Reply and link click are defensible; open is not.
Agree the phone call status reason list with sales operations before building any call-based conditions, and make the field mandatory on close if the branching depends on it.
Keep a plain-English description of each branch in the sequence description field. Six months on, the canvas alone won't tell anyone why the No path waits four days.

Worth another look if the timeout flow architecture changes, or if condition types are extended beyond email, phone, field and BPF stage.