> For the complete documentation index, see [llms.txt](https://docs.dinmo.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dinmo.io/journeys/steps-and-branches.md). # Configure Journey steps and branches After configuring who can enter a Journey, add steps to define what happens to each profile and in which order. Steps can delay progression, split profiles into branches, activate destinations, or end a path. Add only the steps required by your use case. ## Add and configure a step 1. Click the **+** button at the point where you want to add a step. 2. Select the step type. 3. Configure the step in the side panel. 4. Save the configuration. You can select an existing step to review or update its configuration while the Journey is editable. {% hint style="info" %} You can insert Segment, Random Split, or Pause Until between existing steps. DinMo keeps the downstream steps and reconnects them to the default branch: **Everyone else** for Segment, **condition met** for Pause Until, or the first variant for Random Split. Review the resulting branches before publishing. {% endhint %} ## Choose the right step | Step | Use it when | | ---------------- | ----------------------------------------------------------------------------------- | | **Wait** | Progression should resume after a fixed duration. | | **Segment** | Profiles should follow different paths based on a current profile field. | | **Random Split** | Profiles should be distributed randomly across percentage-based variants. | | **Pause Until** | Progression should resume when a profile condition becomes true or an event occurs. | | **Activate** | Profiles should be sent to one or more activation targets. | | **Stop** | A path should end explicitly. | ## Delay progression with Wait Wait keeps profiles at the current point for a fixed duration. Set a positive whole number and choose one of the following units: * hours; * days; * weeks. The total duration cannot exceed 365 days. For example, you can add a Wait before an Activate step when profiles should not be sent to a destination immediately after entering the Journey. Use Wait when elapsed time is the only condition. If progression should resume as soon as a profile attribute changes or an event occurs, use Pause Until instead. ## Create branches with Segment Segment routes profiles according to the value of a field in the Customer Hub profile model. Select a supported categorical or Boolean field, then create the groups that should have their own paths.
Segment configuration panel showing the profile model and field selector

Select the profile field that DinMo should use to create the branches.

Each group must: * have a unique name; * contain at least one field value; * use values that are not already assigned to another group. A Segment can contain up to 10 configured groups. DinMo also creates an **Everyone else** branch for profiles whose value does not belong to any configured group. For example, you can create separate branches for different membership tiers. Profiles with any other value continue through **Everyone else**. {% hint style="info" %} Segment uses the profile field value available when the profile reaches the step. Later changes do not move the profile to another Segment branch. {% endhint %} ## Wait for a condition with Pause Until Pause Until keeps a profile at the current point until a condition is met. Give the condition a clear name, then choose its source: | Condition source | Configuration | | ------------------ | -------------------------------------------------------------------------------------------------------- | | **Profile fields** | Define one or more conditions using fields from the Customer Hub profile model. | | **Event table** | Select an event model, set the minimum number of occurrences, and optionally filter the relevant events. |
Pause Until configuration panel showing profile and event condition sources and an optional maximum duration

Choose the condition source and decide whether profiles need a timed-out path.

For example, you can pause a profile until its lifecycle status changes or until a purchase event occurs. ### Add a maximum duration A maximum duration is optional. Enter a positive whole number in hours, days, or weeks, up to a total of 365 days. * Without a maximum duration, the step has one outgoing path. Profiles remain paused until the condition is met. * With a maximum duration, the step has a **condition met** path and a **timed out** path. {% hint style="warning" %} Without a maximum duration, profiles can remain in the step indefinitely. Add a maximum duration when the condition may never become true. {% endhint %} Conditions are checked according to the Journey processing schedule. A profile progresses the next time the Journey processes it after the condition is met or the maximum duration is reached. ## Activate destinations Activate sends Customer Hub profiles to one or more audience or event destinations when they reach the step. DinMo only lists targets that can synchronize audiences or create new events. Destinations that adjust or retract existing events are not available in Journeys. ### Configure an Activate step 1. Add an **Activate** step. 2. Enter a step name. This name appears on the Journey canvas and in the run history. 3. Select an audience or event destination. 4. Configure its destination-specific settings and map fields from the Customer Hub profile model. 5. For an audience destination, choose the **Sync mode** for this destination: * **Mirror** adds profiles when they reach the step and removes them when their Journey instance exits or finishes. * **Insert only** adds profiles when they reach the step and keeps them in the destination audience after their Journey instance exits or finishes. 6. For an event destination, the sync mode is fixed to **Insert only**. Each passage creates a new event. Previously sent events are never updated or removed. 7. Select **Save configuration**. 8. Repeat these steps for every destination required in the same Activate step, then save the step. Every selected destination must be configured before the Activate step can be saved. When an activation target already uses the Customer Hub profile model, DinMo can prefill its existing mapping. Review the mapping before saving. When configuring an event destination, you can map destination fields from: * fields in the Customer Hub profile model; * the **Journey event ID**, which identifies the passage and remains stable across retries; * the **Journey event time**, which records when the profile reached the step; * a **Static value** entered directly in the mapping row. DinMo uses the destination field's expected type when one is defined. For custom event properties, it infers `true` or `false` as Boolean values, whole numbers as integers, finite decimal or scientific values as decimals, and other input as text. For array fields, enter a valid JSON array. Static values are validated before the destination configuration can be saved. There is no separate type selector. The Journey continues immediately after the profile reaches the event destination. An unfinished event remains eligible for retry for 30 days, using the same event ID and captured values. For example, you can add an Activate step after a Wait, Segment, or Pause Until step to send only the profiles that reach that point. {% hint style="warning" %} An Activate step placed directly after Start sends profiles as soon as they enter. DinMo displays a warning so you can confirm that the immediate activation is intentional. {% endhint %} The same activation target can be selected in several Activate steps, but DinMo flags this configuration for review because the same profile may be activated more than once. {% hint style="info" %} An activation target used by a published Journey cannot be deleted. {% endhint %} ## End each path with Stop Stop explicitly ends a path. A Stop step has no outgoing connection and a profile that reaches it has completed its current Journey occurrence. Every path must end with Stop before the Journey can be published.
Journey canvas showing a Stop step at the end of a path

Stop makes the end of a path explicit in the canvas.

For example, add Stop after the last action in each Segment or Pause Until branch so that every possible outcome has a visible ending. ## Build valid paths DinMo supports flexible paths, including consecutive Segment or Wait steps, nested Random Split steps, and a Wait step after Pause Until. Before publication, DinMo checks that: * every step except Start has a single parent; * every step is reachable and the graph contains no cycle; * branches cannot merge back into the same step; * every path must end with Stop; * Stop remains terminal; * an Activate step does not immediately follow another Activate step; * the Journey contains no more than 50 steps and 10 levels. A Wait step may appear immediately before Stop. When Journey Repeat is disabled, DinMo displays a warning because this Wait only delays completion. Use the publish checklist to distinguish blocking errors from warnings before making the Journey active. ## Related pages * [Configure entry, re-entry, and exit rules](/journeys/entry-rules.md) * [Quickstart: create and launch your first Journey](/journeys/create-your-first-journey.md) * [Design reliable Journeys](/journeys/best-practices.md) * [Monitor and troubleshoot a Journey](/journeys/monitoring-and-troubleshooting.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.dinmo.io/journeys/steps-and-branches.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.