Conditional branching: different customer paths in one workflow

Tuesday, 9:40 a.m. A sales team at an education software company is running a single welcome workflow: everyone who submits the form gets the same email and lands with the next rep in the rotation. That morning the form collects 34 entries. Most are individual teachers, a handful are small tutoring centres, and four come from a school group with several hundred students. All three get the same line: "Your 14-day free account is ready." The procurement lead at the school group deletes it unopened, because her question was never about a trial — it was about contracts, invoicing and how far the seat count scales. On Friday the team looks at the conversion rate and concludes the workflow does not work. The workflow works fine. It only knows one route.

Conditional branching is the answer to exactly that: one trigger, one workflow, several routes chosen from the data on the record. This article starts with where a single-route workflow breaks and which data a branching decision should rest on. A table then compares trigger filters, if/else branches and separate workflows, and the section after it shows why condition order changes the outcome. The rest covers branch count, waits inside branches, diagnosing a route that never fires, testing before launch, and which numbers mean anything once a workflow splits.

Where does a single-route workflow break?

A single-route workflow is an assumption in disguise: everyone arriving through this trigger wants the same thing. At low volume nobody notices, because people quietly absorb the mismatch — a rep sees the wrong message go out and adds a sentence of their own. At higher volume there is nobody left to absorb it, and the workflow becomes visible exactly as it was written.

The break usually happens in one of three places. Source is the first: a request from your pricing page and a reply pulled out of a cold list are not at the same stage of intent. The reasoning behind managing inbound and outbound leads differently works just as well as two branches inside one workflow. Size is the second: a single-seat request and a multi-department rollout cannot carry the same follow-up rhythm. Timing is the third: a request that lands at 11 p.m. cannot be treated like one that lands mid-morning.

What these three have in common is that better copy fixes none of them. However well written, one message sits at the average of three different needs — and an average message convinces nobody, it merely offends nobody. Branching is how you leave that average behind.

Which data should carry the branching decision?

A branch is worth exactly as much as the field it reads, and that field has to be populated when the workflow runs. Built on a question you never asked on the form, a branch behaves like no branch at all: the condition returns empty and everyone lands in the catch-all. Branch design therefore starts as data-capture design — decide which question settles the decision, then put that field on the form.

Good branching data has three properties: it lives on the record, it takes a small set of values, and it does not shift while the decision is being made. Company size, request type, industry, source channel and budget band all qualify. Judgement fields like "interest level" do not, because two reps will label the same record differently. If you already track which stage a record sits in, mapping the customer lifecycle stage by stage hands you a consistent axis to branch on.

In the product this is Multiple Triggers working with the Conditional Branching step: a form submission, webhook, schedule or inbound message starts the run, and the if/else step right after it reads the record's fields and picks the route. The decision lives in the workflow, not in somebody's head — six months later, the answer to "why did this account go down the fast-response route" sits in the step's condition.

Filter, branch or separate workflow — which one?

Not every difference deserves a branch. Some splits belong before the workflow starts, some in the middle, and some in a workflow of their own; the wrong instrument makes the automation either needlessly tangled or needlessly blunt. The table below sets out the criteria.

Instrument	Use it when	What it hides
Trigger filter	A group should never enter the workflow at all; the split is known upfront	Filtered records show up nowhere and disappear quietly
If/else branch	Routes reach the same goal differently but share most of their steps	The canvas stops being readable as branch count grows
Separate workflow	The two routes have different triggers, owners and success measures	Shared steps now need maintaining in two places
Sub-workflow call	The same sequence repeats across several workflows	Long chains make it harder to see which workflow did what

A workable threshold: if two routes share more than half their steps, branch; if they do not, write a second workflow. When the shared part shows up in a third workflow as well, pull it into one place with the Sub-workflow Call step, where loop and depth protection keep the chain from biting its own tail. Once you have the general habit of automating processes with conditional rules, choosing between these three is an architecture call rather than a technical obstacle.

How does condition order change the outcome?

An if/else chain reads top to bottom and the first matching condition wins. That simple rule is behind the single most common defect in branched workflows: a broad condition sitting above a narrow one. Put "industry is education" above "more than 500 seats" and the large school group can never reach the enterprise route. The branch is built correctly; the order is wrong.

The fix is to arrange conditions from narrow to broad — most specific at the top, most general at the bottom. Always finish with a catch-all route so a record that matches nothing does not stall halfway through. In most designs that route does one thing only: it creates a task and tells a human that this record could not be classified.

The ordering argument is really the technical face of an old sales distinction. Because B2B and B2C selling are two different games, two records from the same form should not travel the same route: one moves in minutes with a single decision-maker, the other stretches across weeks of committee review and budget cycles. Condition order is where that distinction gets written into the workflow.

How many branches are too many?

There is no technical ceiling on branch count, but there is a practical one: the team has to read the workflow on a single screen. Experienced teams usually ship the first version with two or three branches. Four or more only earns its place when each branch genuinely has a different message, a different owner or a different cadence.

The quickest test of whether a branch is justified is to ask what changes for the customer if you delete it. If the answer is "one sentence of the message," use a variable inside the message instead. If the answer is "who calls, when they call and what they offer," the branch is real. The logic that separates enterprise selling from SMB selling applies directly here: when two routes have different counterparts and different rhythms, one message cannot do both jobs.

The opposite mistake exists too. If a workflow has one "large account" route and half the records in it are simply multi-seat companies on a small budget, that route is waiting to be split again — visible in the spread of response times inside it, not in the conversion rate.

What do waits and timing change inside a branch?

Branching separates not only what gets sent but when. A five-minute wait suits a route where one person decides; the same five-minute follow-up is intrusive on a route that moves through a committee. Wait durations can and should differ between two branches of the same workflow.

Alongside the Scheduler step, two safeguards matter here. Rate and Business-Hours Limits set an execution ceiling per hour, day or week plus a working-hours window, so a record that lands at 3 a.m. waits for the morning. Stop on Reply cancels pending steps the moment the person answers or the lead closes, so nobody receives a third reminder while their reply is still open in the inbox.

Waits pay off most visibly in date-driven processes. The reminder sequence that brings the no-show rate down is really branching built on timing conditions: a booking a day out follows one route, a booking later the same day follows another.

Operations works the same way. When status-change notifications become a proper automated order status update flow, each status gets its own route and its own wait — a shipped order is announced immediately, while an order still being packed waits until the next working day.

Where do you look when a branch never fires?

In branched workflows the nastiest fault is the one that throws no error. The workflow looks healthy, the run count climbs, and one route reaches nobody. The cause is nearly always one of three: the condition is in the wrong order, the field it reads is empty, or the channel on that route was never connected.

Run History is the shortest way to tell those apart: you see which steps each record passed through, with the value the condition actually compared. Automatic Diagnostics surfaces disconnected steps, workflows that never fired and unconnected channels without you going looking. Funnel Analytics shows the exact step where people drop — a route that flatlines right after step one has a condition problem, not a copy problem.

The last link in diagnosis is human. The catch-all route you built for unclassifiable records should not be an empty branch — it should produce a task. Standardising automatic task creation with templates is what turns that route into a queue rather than a bin.

How do you test branching before going live?

A first real run on live customers is expensive: an enterprise request in the wrong route leaves a first impression you cannot take back. The Dry Run Test exists for that — it walks the workflow end to end on sample data, shows step by step which path would execute, and sends no real email, WhatsApp or SMS.

When you test, prepare one sample record per route plus one that matches no condition at all. For a four-route workflow that means five test records. If the route you expected and the route that fired are not the same, what you need to change is the condition, not the message.

Your way back stays open after launch. Version History keeps every save as a version, so a broken workflow reverts in a click and the state before the rollback is kept too. On a risky route — the one sending a discount offer, say — an Approval Step pauses the run, notifies the person you nominate, and refuses to continue unapproved once the window expires.

Which numbers matter once a workflow branches?

The moment you branch, the workflow's overall conversion rate turns into a misleading number. An average across two routes hides the strong one underneath the weak one. So the measurement has to branch as well: records entered, first response time, in-route completion rate and opportunities created, read separately for each route.

Per-route reading first tells you whether the branch was needed at all: near-identical numbers mean it is probably surplus, a persistent gap means it is doing its job. It also tells you which route is worth improving — a few points on a low-volume, high-value route can beat the same lift on the busy one.

Pair the counts with an experience measure. Comparing how the routes feel on the customer's side is what measuring satisfaction with NPS, CSAT and CES is for: ask records leaving different routes the same question, and the scores show which cadence lands as heavy-handed.

Watching the tone of incoming replies gives you an earlier warning still. Sentiment analysis that catches dissatisfaction early flags an over-messaging route before the conversion rate moves; a sharp turn in one route usually means its waits are too short.

To build your first branch and put it through a dry run, you can open a free Rocketly account.

FAQ

How many branches can one workflow have?

The real limit is readability rather than a number. Ship the first version with two or three; if you cannot name a distinct message, owner or cadence for a branch, collapse it into a variable inside the message instead. Past the fourth branch, pulling shared steps into a Sub-workflow Call keeps the canvas legible.

What happens if the field a condition reads is empty?

The record fails that condition and moves to the next one in the chain; if it matches none, it lands in the catch-all route at the bottom. That is why every branched workflow needs a catch-all and why that route should create a task — otherwise unclassifiable records slide silently to the end of the run.

What happens to in-flight records if I change the branches?

Nothing goes live until you save; from that moment new runs start on the new version. Check Run History to see how records already waiting behave, and if the result is not what you expected, Version History takes you back to the previous version.

Can I build branching with the AI Copilot?

Yes. Describe the split in plain language and Copilot builds the conditional step on the canvas; your follow-up messages edit the workflow that is already there. Copilot never publishes anything on its own — it updates the draft, and the decision to save stays with you.