Designing safe journeys

Safe Journey design reduces launch risk and makes operational behavior easier to explain — to your team, your reviewers, and yourself when you come back to it three weeks later.

Core design principles

1. Keep the entry logic simple

Start with one clear entry rule before adding more conditions. Multiple OR or AND rules can make it hard to predict how many contacts will enter and why.

If you need multiple entry conditions, make sure the business logic is documented and the combined rule is explainable in one sentence.

2. Delay before the first activation

Add a Wait step before the first Activate unless immediate activation is a deliberate business choice.

Why this matters:

• Contacts who entered by mistake have not yet been sent to a destination

• The first run can be monitored before activation happens

• Timing is easier to reason about when there is a buffer

Placing Activate directly after Start means contacts are activated as soon as they enter. If this is unintentional, you may need to pause the Journey and remove affected contacts from the destination manually.

3. Define how contacts leave

Every Journey should have a clear exit path — either through a Stop step at the end of each branch, through exit rules, or both.

If you do not define exit rules, contacts will complete the full Journey regardless of what happens after they enter (including if they convert, churn, or become irrelevant). Use exit rules whenever there is a business event that should immediately stop the flow.

4. Avoid unnecessary branching

A Segment step should only be used when the downstream paths are meaningfully different. If all branches end up doing the same thing, remove the Segment and simplify.

Every branch you add is one more path to validate, monitor, and explain.

5. Prefer readability over cleverness

If the canvas is hard to explain in a one-sentence summary, it is probably too complex to maintain safely. Complex flows are harder to review before launch and harder to debug after something goes wrong.

A readable Journey:

• Has named branches that describe the business logic

• Has a visible ending on every path

• Can be explained by someone who did not build it

Pre-launch checklist

Before publishing any Journey — first time or after editing — work through this checklist:

Entry and exit:

• Can someone else explain who enters the Journey and why?

• Is there a clear exit path — via Stop nodes, exit rules, or both?

• If re-entry is enabled, is there a Wait before the first activation?

Activation timing:

• Is the first activation timing intentional? (Is there a Wait before the first Activate?)

• Are all Wait durations business-justified?

• Is the Pause Until timeout set and appropriate?

Branching:

• Are all Segment branch names readable?

• Is every branch — including the other branch — connected to a downstream step or a Stop?

• Are both paths of every Pause Until step (condition met and timeout) connected?

Destinations:

• Does every Activate step have at least one destination configured?

• Has duplicate destination use been reviewed?

Final check:

• Has the publish checklist been reviewed with no unresolved blocking errors?

• Are any warnings understood and accepted?

Operational advice

Launch the simplest version first

Start with the minimal viable shape — Start → Wait → Activate → Stop. Validate that it works as expected before adding Segment, Pause Until, or complex branching.

Make one meaningful change at a time

When editing a live Journey (paused), change one thing, re-publish, and monitor before making the next change. Multiple simultaneous changes make it hard to identify what caused an unexpected result.

Use run history after every launch or major edit

Check run history immediately after publishing or resuming. Confirm:

• The run started successfully

• Entry volume matches expectations

• No unexpected failures occurred

Test with a small audience first

If possible, test a new Journey with a narrow entry rule (a small, known audience) before expanding to the full population. This limits the blast radius if something is misconfigured.

Related pages

• Create your first Journey

• Publish, Pause, and Resume a Journey

• Common validation issues

• Choosing Wait vs Pause Until