How a branch works
A branch asks a question and sends people down different paths depending on the answer. Has this person bought before? Did they open the last message? Which country are they in? Which item did they look at? Everyone who meets the condition takes one route; everyone else takes the other.
The important detail is when the question is asked. The platform checks the condition at the instant the person reaches the branch step, not when they entered the flow. Somebody who bought while sitting in a wait step is evaluated as a buyer; if the branch sat before that wait, they would have been evaluated as a non-buyer. Moving a branch by one step changes who goes where.
Branches can be nested, so a path can split again. They can also be split on a percentage of traffic for testing, though that is a different feature with a different purpose and mixing the two makes results impossible to read.
Why branches matter
They let one sequence serve several audiences without maintaining several sequences. A single post-purchase flow can thank a first-time buyer and treat a returning customer differently, rather than sending the same introduction to somebody on their fifth order.
They also stop the obvious mistakes that damage trust. A branch that checks whether an item is in stock before recommending it, or whether a client has already booked before chasing them, prevents the emails that make a business look as though it is not paying attention. Relevance of this kind costs nothing beyond thought — it is segmentation applied inside a sequence rather than across a list.
Where branches go wrong
Branching on data you do not reliably hold is the biggest one. If the industry field is only filled in for a handful of contacts, a branch on industry sends nearly everyone down the fallback path, and the tailored version you spent an afternoon writing is barely ever seen. Check how often a field is actually populated before you build a decision on it.
Over-branching is the other. Every split doubles the number of paths to write, proofread and test, and a flow with many nested conditions quickly reaches the point where nobody on the team can say with confidence what a given contact will receive. Complexity that cannot be tested is a fault waiting to surface in front of a customer.
How to build them well
Only branch where the message genuinely changes. If both paths end in nearly the same email, delete the branch and use a personalisation token instead — it achieves the same thing with none of the maintenance.
Before building, check the fill rate of every field you plan to test, and write the fallback path assuming the data is missing, because for many contacts it will be. Keep the number of paths small enough that you can walk each one end to end, and then actually walk them: create test contacts that match each condition, run them through, and read what arrives.