Branching in business process flows

What it does

Branching lets one business process flow take different stage paths depending on data in the record. You drop a Condition between stages, and at runtime the platform evaluates it and sends the deal down the matching branch — so a high-value deal can pick up an approval stage that a small one skips.

Key facts

A condition can combine multiple expressions, but a single rule uses either AND or OR throughout. You can't mix the two in one condition, so complex logic has to be split across conditions or moved out of the BPF.
Branch conditions can only reference steps in the stage immediately before the condition. If the field you want to branch on isn't a step on that stage, add it as a step or the branch can't see it.
Evaluation happens in real time as the user advances. It's driven by business rules under the covers — changes made purely through the Client API don't re-trigger condition evaluation.
Peer branches must all converge on a single stage, or every peer branch must end the process. One branch merging while its sibling ends the process is not a valid design.
The rest of the BPF limits still apply to a branched process: 30 stages per process, 30 steps per stage, 5 unique tables.
Microsoft's own pages disagree on branch depth — the branching article says 5 levels deep, the create-a-BPF article says 10. Treat anything past 5 as unsupported until you've tested it in the target environment.
Branching is a design-time construct only. There's no way for a seller to choose a branch manually; the data decides.
A table can appear more than once in a branched process, so closed loops (back to Opportunity after a detour) are allowed.
Users can still move backwards through stages, including across a branch boundary, which means the record can end up re-evaluating a condition on the way forward again.

When to use / skip

Use branching when the same deal type genuinely forks — an enterprise deal needing a legal review stage, a public sector deal needing a tender stage, a renewal that skips discovery. It keeps one process and one BPF table, which is much kinder to reporting than maintaining two near-identical processes.

Skip it when the fork is really about which fields matter rather than which stages exist. If both paths have the same stages and only differ in required data, use business rules on the form to show and require different fields, and leave the process linear.

Also skip it when the branching condition depends on something the seller hasn't entered yet at that point in the deal. The condition reads the preceding stage only, so branching early on data that arrives late produces deals stuck on the wrong path, and the fix is manual.

Most mid-market Sales projects don't need branching at all. It's worth reaching for when a client has two or three real sales motions that share 70% of their stages.

Configuration decisions

Which field drives the branch, and whether it's reliably populated by the time the preceding stage completes. Estimated revenue and a deal-type choice column are the usual candidates.
Whether the branch is a genuine fork or a skip — an optional stage that most deals bypass is often simpler modelled as a branch with a short path than as two long paths.
Where the branches merge, and whether the shared closing stages sit after the merge point so that close-stage reporting stays consistent.
Whether branch paths span different tables. Doing both at once (branching plus multi-table) is the hardest BPF shape to test and to debug.
How you'll handle a deal whose driving field changes after the branch is taken — leave it, or automate a stage correction.

Gotchas

Adding a step to a stage after go-live doesn't retro-apply to in-flight records, and a branch condition referencing that new step may evaluate against an empty value for deals already sitting on that stage.
Because the condition reads only the immediately preceding stage, moving a stage during a redesign can silently break a branch. Validate the process after any stage reorder.
Changing the driving field's value on a record that's already past the condition doesn't re-route it. The traversed path is fixed unless someone walks the record back.
Branch conditions using OR across many values are easy to write and hard to read six months later. Document the intent somewhere the client can find it, because the process designer shows the logic but not the reason.
Deep branching plus multi-table means a user can be shown a stage belonging to a record they have no read access to. Check this with real roles before go-live.
Validation only catches structural problems (unmerged peers, invalid depth). It won't tell you the condition never evaluates true.

Consultant notes

Draw the branched process on a whiteboard with the client before building. Almost every branching conversation ends with the client realising they wanted three stages, not two paths.
Test each path end to end with a seller-level account, including walking a deal backwards over the merge point. That's where the surprises are.
If a client asks for branching on a field a manager sets later, tell them plainly it won't work and offer a second process or a manual stage set instead.
Keep a copy of the process design (the snapshot feature in the designer is enough) with the solution documentation. Reading branch logic back out of a live process is slow.
Before go-live, confirm which depth limit your tenant actually enforces if the design goes beyond a couple of levels.

Worth another look if Microsoft reconciles the 5-versus-10 branch depth in the docs, or if the client adds a third sales motion to an already branched process.