# 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 {% hint style="warning" %} 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. {% endhint %} ### 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](/journey/getting-started/create-your-first-journey.md) * [Publish, Pause, and Resume a Journey](/journey/getting-started/publish-pause-and-resume-a-journey.md) * [Common validation issues](/journey/monitoring-and-troubleshooting/common-validation-issues.md) * [Choosing Wait vs Pause Until](/journey/best-practices/choosing-wait-vs-pause-until.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.dinmo.io/journey/best-practices/designing-safe-journeys.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.