Branching and timing

Not every contact should follow the exact same path through a journey, and not every step should happen the instant the journey reaches it. Branch steps split contacts onto different paths based on a condition, and timing steps pause the journey for a while before it continues. Together they let you build journeys that feel personal and well-timed instead of one rigid sequence that fires the same way for everyone.

The branch types

If / Else — splits contacts two ways based on a condition you set, such as a field value, a tag, or whether they're in a segment. Contacts who match go down the "true" path; everyone else goes down the "false" path.
Switch — like If / Else, but for more than two outcomes. You set up several conditions, and each contact follows the first one they match. Anyone who doesn't match any of your conditions falls through to a default path, so it's worth deciding what should happen there too.
A/B split — splits contacts randomly by a percentage you choose, so you can test two or more versions of what happens next (for example, two different subject lines) and compare results.
Engagement split — splits contacts based on how they engaged with a previous email or text — for example, opened, clicked, or bounced — each outcome going down its own path, plus a path for contacts who didn't respond at all. Use it right after a send step to react differently depending on how someone did (or didn't) engage.
Event attendance — splits contacts by what they did about a marketing event: Attended, No show, and Cancelled, each with its own path. You pick the event it checks against — a specific one, or This journey's own campaign event, which lets the same journey serve whichever event the campaign is running without editing it. Use it after an event has happened to thank the people who came and follow up differently with those who didn't. Note there is no path for "never registered": a contact who matches none of the three stops there, so anything that should happen regardless of attendance belongs before this branch rather than after it. See Marketing events.
Merge / Join — brings two or more branches back together into a single path, so the journey continues the same way for everyone regardless of which branch they took earlier.

How conditions compare values

A condition compares a contact's field with the value you typed, and it compares them as the field's kind of value, not as text:

Numbers compare as numbers — "Score is greater than 10" matches 11 and 10.5, not 9, and "Score = 10" matches a score of 10.
Yes / no fields — including Do not contact and its email and SMS versions, and your own yes / no custom fields — offer is checked / is not checked, with no value to type. Is checked matches only a contact whose field is yes (true, or a stored "yes", "true" or 1). Is not checked matches everyone else: a field that's no (false), and also one that was never filled in — an empty yes / no field counts as an unticked box, so those contacts go down the "is not checked" path. A journey published earlier with = true / false (yes / no and 1 / 0 work too) or a text operator like "contains" still works — = compares as yes / no, "contains" reads the field as "true" or "false" — and the step shows that operator as it was saved.
Dates compare as dates — "Birthday is before 1990-05-17" matches anyone born earlier.
A date against a date-and-time field compares by calendar day (in UTC): "Last purchase = 2026-03-01" matches any time that day, "on or before 2026-03-01" includes the whole day, and "after 2026-03-01" starts at midnight on the 2nd.
Text compares exactly as typed, including upper and lower case: "City = Boston" doesn't match "boston".
Owner is picked from your workspace's users by name, and compares the user: = / ≠ one user, in / not in several, or is set / is empty. Text operators like "contains" aren't offered — an owner is a person, not a piece of text — and a journey saved earlier with one won't publish until you change it.
CRM reference fields (a linked account or owner synced from your CRM) match by their name or their CRM id: "Account = Acme Corp" and "Account = 0018d00000AbCdE" both work. "Contains", "starts with" and "ends with" look at the name.
Is empty / is set — a field is empty when it has no value, or only spaces. A 0 or a "no" is a value, so "Score is empty" doesn't match a score of 0; use "Score = 0" for that.
Leaving the value blank — "Score = (blank)" means the score is empty, and "Score ≠ (blank)" means it has one.

If the value you typed can't be read as the field's kind — "abc" on a number field, say — the condition doesn't match anyone, so double-check a branch whose contacts all go down the same path.

The timing types

Wait — pauses the contact's journey for a fixed amount of time (for example, two days) before moving on to the next step. A wait of zero is allowed and means "no delay" — the contact moves straight on, which is how a step that should happen immediately is expressed.
Wait until — pauses until a specific date, time, or condition is met, rather than a fixed length of time. Useful for waiting until a renewal date or until a field changes. A reminder journey can also wait relative to a marketing event's own start time — a week before, a day before, a few hours before, or right at the start — instead of a fixed date. Because the wait is tied to the event rather than a calendar date, rescheduling the event moves every reminder along with it automatically, with nothing to go back and re-time. To set it up, change Wait relative to from a fixed date to the event's start time, then pick the event and how far from it to fire — a number, a unit (minutes, hours or days), and whether that falls before the event or after it. So a week before, a day before, three hours before, two hours after, or — by setting the number to zero — right at the start. See Marketing events.
Send window — restricts when a later send can go out, so messages only deliver during hours you allow (for example, weekday mornings) even if the journey reaches that step outside those hours.

Repeating steps: Go to, and no loops

A journey moves forward. A connection — the next line out of a step, a branch path, or a step's error path — can never lead back to a step the contact has already passed, and a step can't connect to itself. Publishing refuses a journey that does, and names every step on the loop, for example:

These steps loop back on themselves: 'Send reminder' (s) →(error) 'Wait 1 hour' (w) → 'Send reminder' (s).

The reason is that nothing would ever stop a contact going round such a loop. "If the send fails, wait an hour and send again" retries the send every hour for ever, and a loop with no wait in it can send dozens of messages in a few seconds.

To repeat steps on purpose, end the loop with a Go to step (in the Control category). Go to jumps back (or ahead) to the step you pick as its Target node, and its Max iterations sets how many times it may jump: a whole number from 1 to 25, or leave it at the default of 10. When a contact has jumped that many times, the run stops and shows as failed in Monitoring. Put a branch before the Go to so contacts who are done take the other path.

A journey published before these rules keeps running, but publishing it again — or making a version of it live — is refused until the loop is fixed. The run itself is also stopped if it loops too long — see loop limits.

Steps

On the journey canvas, open the step palette and switch to the Branch or Timing category, depending on which kind of step you want.
Drag the step onto the canvas, or click it to drop it in, then connect it to the step before it.
Click the new step to open its settings panel.
For a branch step, set the condition (or conditions, for Switch) that decides which path a contact takes, or the percentage split for A/B split. Each condition is a field, an operator and a value. A value you type or pick from one short list sits on the same line; a value that needs more room — picking an Owner or Tags, a Timezone, two numbers or dates for a range, or several options at once — gets its own line under the field and operator.
For a timing step, set the wait duration, the condition or date to wait until, or the allowed hours for a send window.
Draw a connection out of each branch path (or out of the timing step) to whatever should happen next. If you want branches to reconnect later, add a Merge / Join step and connect each branch into it.
Your changes save automatically. Publish the journey when you're ready for it to run for real contacts.

Tips

Give each branch a clear condition before you connect anything after it — an unfinished condition can leave contacts stuck with nowhere to go.
Use Merge / Join when branches should end up doing the same thing afterward, so you don't have to duplicate the same steps on every path.
A Wait step is the simplest way to space out messages so a journey doesn't feel like a burst of activity all at once.
For a checkbox form field (like an email-consent opt-in), use the is checked / is not checked operators rather than "is set". A checkbox always submits a value — ticked or not — so "is set" would match either way; "is checked" is what actually tells the two apart.
A branch can test more than one thing at once. Click + Add condition and an AND / OR control appears between them: AND means a contact has to match every condition, OR means matching any one is enough. A form with two consent checkboxes, for example, usually wants OR — "ticked either box". The control only appears once there are two conditions, because with one there is nothing to join.

FAQ

Q: What happens to a contact while they're waiting on a Wait or Wait until step? A: They stay enrolled in the journey and simply haven't reached the next step yet. They'll continue automatically once the wait ends or the condition is met.

Q: Can I use a send window without a Wait step? A: Yes. A send window only restricts the hours a send can go out — it doesn't add a delay on its own, so use a Wait or Wait until step first if you also want to hold the contact for a specific amount of time.

Q: I re-submitted the test form with the checkbox ticked and the journey still took the other path. Is the condition broken? A: Probably not — check whether a run was created at all. A contact only enters a journey once unless Allow re-entry is switched on in journey settings, so your second and later submissions with the same email address are skipped entirely, and what you're looking at is still the result of the first one. The journey's Events tab reports these as Skipped. Either switch on Allow re-entry — and leave 30 seconds between attempts, because re-entry has a 30-second cooldown (see Re-entry limits) — or test each variation with a different email address.

Q: Contacts who never answered my yes / no field went down the "is not checked" path. Is that right? A: Yes. A yes / no field that was never filled in counts as unticked, the same as a form checkbox left blank. If "never answered" needs a path of its own, use a choice field with Yes and No options instead: a choice field offers is empty as well as = Yes / = No.

Q: Publish says "These steps loop back on themselves". How do I retry a failed send? A: Connections can't lead back to an earlier step, so an error path back to the same send isn't allowed — it would retry for ever. Connect the error path forward instead (to a notify step, a different channel, or the end). If you really do want to try again a limited number of times, route the error path through a Wait and then a Go to that targets the send, with Max iterations set to how many tries you want (1 to 25).

Know what happens when the tries run out. If the send is still failing after the last one — an outage that lasts longer than Max iterations × the wait, say — the Go to stops the run, it shows as failed, and Retry is off for it: a Go to that has used up its Max iterations counts as a loop limit. So put a Notify step on the error path before the Wait, so someone hears about the failures while they are happening, and once the problem is fixed, enrol the contact again.

Q: My If/Else on a consent checkbox always takes the same path — why? A: A checkbox reports a value whether or not it's ticked, so an "is set" condition matches both. Pick the checkbox field and use is checked (or is not checked) instead — that reads the ticked/unticked state itself, so an unchecked box correctly follows the Else path.