Design reliable Journeys
A reliable Journey should make it easy to understand who enters, what happens to each profile, and when profiles leave.
Before publishing, someone who did not build the Journey should be able to review its behavior without having to inspect every configuration detail.
Start with the expected outcome
Before adding steps, define:
Who should enter the Journey.
What should happen after entry.
Which destinations may receive profiles.
What should cause a profile to leave.
Whether profiles should be allowed to enter again.
What should happen when an expected event never occurs.
Keeping this outcome clear makes it easier to choose the appropriate steps and avoid unnecessary branches.
Keep entry and re-entry under control
Use entry rules that are easy to explain and verify.
When combining several conditions, check the AND/OR logic carefully. A broader rule may enroll significantly more profiles than expected, while an overly restrictive rule may prevent anyone from entering.
Also consider when the underlying source data is refreshed. A Journey can only evaluate the data available when it runs.
If re-entry is enabled:
Confirm that repeated activation is intentional.
Configure an appropriate re-entry delay.
Consider adding a Wait before the first Activate step.
Check that the full Journey duration is consistent with the expected re-entry frequency.
For example, you can add a Wait before the first activation to prevent a profile from completing and re-entering the Journey too quickly.
Choose between Wait and Pause Until
Wait and Pause Until both delay progression, but they address different needs.
Wait
Pause Until
Progresses when
A fixed duration has elapsed
A condition is met or the maximum duration is reached
Number of paths
One
One, or two when a maximum duration is configured
Can progress early
No
Yes
Best suited for
Time-based sequencing
Event- or condition-based sequencing
Use Wait for a fixed delay
Use Wait when the next step should always happen after a defined duration.
For example, you can add a Wait condition to delay an activation for several hours or days after entry.
Avoid splitting a simple delay into several consecutive Wait steps. A single, clearly configured Wait is easier to understand and monitor.
Use Pause Until for a condition
Use Pause Until when progression depends on an event or a profile attribute.
For example, you can pause profiles until they complete a purchase, reach a specific status, or trigger another expected event.
When a maximum duration is configured, Pause Until creates two paths:
The condition was met.
The maximum duration was reached.
Both paths should represent an intentional outcome and lead to another step or a Stop step.
Use a maximum duration that reflects a meaningful business deadline. A very short duration may not leave enough time for the condition to occur, while a very long duration may leave profiles waiting longer than intended.
Keep branches purposeful
Use a Segment step when profiles should follow meaningfully different paths.
Before adding a branch, ask whether each group leads to different timing, activation, or exit behavior. If the paths immediately converge or perform the same actions, the branch may be unnecessary.
For every Segment step:
Make each group definition easy to understand.
Review the Everyone else path.
Connect every group to a downstream step.
End every completed path with a Stop step.
Limit the number of branches and nested decisions where possible. A smaller number of clear paths is easier to validate and troubleshoot.
Make every exit intentional
Stop steps and exit rules solve different problems:
A Stop step marks the normal end of a specific path.
An exit rule removes a profile from the Journey when it is no longer relevant, regardless of its current step.
Every branch must end with a Stop step, even when exit rules are configured.
Use exit rules when a business event should prevent further progression. For example, you can make profiles leave the Journey after they convert, unsubscribe, or no longer meet an eligibility condition.
Check that exit rules are not broader than intended. A profile that matches an exit rule cannot continue to later steps in the Journey.
Reduce activation risk
An Activate step can update one or several destinations. Before publishing, verify that each activation is expected and correctly timed.
Consider adding a Wait before the first Activate step unless profiles should be activated immediately after entry.
Also check that:
Every Activate step has the intended destinations.
The same destination is not used in several steps unintentionally.
Each branch activates only the profiles it is designed for.
Exit rules can remove profiles before an activation that is no longer relevant.
The expected entry volume is appropriate for the destination.
When possible, start with a narrow entry audience and monitor the first executions before expanding the Journey to a larger population.
Review the complete path before publishing
Follow every possible path from Start to Stop, including fallback and timeout paths.
Entry and re-entry
Timing
Branches and exits
Activations
Publication
Change a published Journey carefully
When updating an existing Journey:
Pause it before editing.
Make one meaningful change at a time.
Review every path affected by the change.
Resolve new validation errors and warnings.
Publish the new version.
Check the first run and the Activity panel.
Making several unrelated changes at once can make unexpected behavior harder to explain. The run history version helps identify which Journey configuration was used for each execution.
Monitor after publication
After publishing or resuming a Journey:
Confirm that the first run completes successfully.
Check that the number of profiles entering is reasonable.
Inspect Activity on important Wait, Pause Until, Segment, and Activate steps.
Confirm that actions are executed at the expected volume.
Investigate failures before triggering another run.
Monitoring the first executions is especially important after changing entry rules, re-entry settings, branching, timing, or destinations.
Related pages
Last updated