Attribute branches versus if/then branches

What it does

Journeys split two ways. An attribute branch reads data the moment the customer arrives at the tile and sends them down one of several paths. An if/then branch — the wait-for-trigger tile — pauses and waits to see whether something happens within a time limit, then splits two ways on the answer.

Key facts

Attribute branches evaluate on arrival, against what is true right then. If/then branches evaluate over a window, against what happens next.
Attribute branches support multiple paths. If/then branches are strictly yes/no.
An attribute branch can read three sources: profile attributes of the journey audience, membership of a segment, and attributes carried on a trigger used in the journey.
Trigger attributes are only available to an attribute branch if that trigger was used at journey start or on an upstream wait-for-trigger tile. You cannot read a trigger the customer never passed through.
Segment membership on an attribute branch is checked at the instant the customer reaches the tile, not continuously.
Date attributes support relative and partial formats, which is how birthday and anniversary branching works — the branch resolves against the date the customer arrives, not the date the journey was published.
If/then branches wait on message interactions (opened, clicked and channel equivalents), on segment membership, or on a trigger attribute reaching a specific date and time.
If/then timeouts are capped at 90 days, same as every other wait in the product.
Multi-interaction branching exists as a separate capability for splitting on which of several interactions occurred, rather than one yes/no on a single interaction.
The audience split tile is a third, unrelated thing: it divides people by percentage or fixed number for A/B purposes, not by any attribute.

When to use / skip

The rule that holds up: attribute branch for what has already happened, if/then for what you hope will happen. Segment membership, opportunity stage, country, language, whether the case was resolved on first contact — attribute branch. Whether they opened the email, whether they registered within 48 hours, whether they bought — if/then.

Where consultants go wrong is using an attribute branch for behaviour, because the data does eventually land in Dataverse. It works, in the sense that it produces a path, but it evaluates once, on arrival, and if the record hasn't been written yet everyone goes down the no path. You then add a plain wait tile in front of it to "give it time", and you have built a worse if/then branch with more moving parts.

The reverse mistake is less common but more expensive: an if/then branch waiting on something that already happened before the customer entered. It waits the full timeout and everyone lands on no.

Configuration decisions

For each split: is the condition historical state or future behaviour? That single question picks the tile.
How many paths the attribute branch needs, and what the fall-through path does for people matching none of the conditions.
Which trigger attributes need to be available downstream, since that constrains where the trigger has to appear in the flow.
Whether segment-based branching is fast enough given the segment's refresh cadence, or whether a profile attribute would be more reliable.
Timeout values on every if/then branch, and whether the no path is a genuine alternative treatment or a quiet exit.
Whether a split is really a branch at all, or whether conditional content inside a single email would do the same job with less journey to maintain.

Gotchas

Attribute branches read data at the moment of arrival. Data written a second later is invisible to that customer, forever, on that journey run.
People matching no condition on a multi-path attribute branch need somewhere to go. Leave that path empty and they end the journey silently, which then shows up as unexplained drop-off in analytics.
Segment membership branching lags segment refresh. A customer whose data changed an hour ago may still branch on their old membership.
Adding or changing a branch condition on a live journey is a major edit — it creates a new version, and people already in flight keep the old logic.
Nested branches multiply the paths you have to test. Four levels of two-way branching is sixteen combinations, and journey previews will not walk them for you.
Branching on "email opened" inherits every accuracy problem of open tracking. Image-proxying mail clients register opens nobody performed.

Consultant notes

Make the client articulate each branch as a sentence starting "if the customer has already…" or "if the customer does…". The wording picks the tile and settles the argument in the room.
Demo the birthday case with a relative date attribute branch. It is the clearest illustration that branches evaluate on arrival, and clients remember it.
Push back on journeys with more than three levels of branching. Two shorter journeys joined by a trigger are almost always easier to test, change and read in analytics.
Before go-live, check every branch has a populated default or no path, and that the totals in analytics reconcile to journey entries.
If the split only changes copy rather than timing or channel, move it into conditional content and delete the branch. Fewer paths, same outcome.

Worth revisiting once multi-interaction branching matures, or if attribute branches gain a re-evaluation option.