# Overview

Build, launch, and monitor customer journeys in DinMo.

<figure><img src="/files/7j3JT3aKLyIS9XilPlV0" alt="Journeys list page showing active and draft journeys with status, mode, and last updated columns"><figcaption><p>The Journeys list — your starting point to create, manage, and monitor all Journeys in the Customer Hub.</p></figcaption></figure>

***

## Who this section is for

* Marketers and lifecycle teams building automated customer flows
* CRM and retention operators responsible for activation timing and orchestration
* Customer success and growth teams reviewing journey results

You do not need warehouse or SQL knowledge to use this section.

***

## What Is a Journey?

A Journey is a workflow that moves contacts through a sequence of steps over time.

In DinMo, you use Journeys to decide:

* **Who** enters a flow
* **When** they wait
* **How** they branch by profile attribute
* **When** they exit early
* **Which destinations** get activated at each point

Journeys are designed for lifecycle orchestration rather than one-time activation. Instead of sending a contact to a destination once, you define a path that reacts to time, profile data, and events.

### What a Journey can do

| Use case                            | How it works                                                                              |
| ----------------------------------- | ----------------------------------------------------------------------------------------- |
| Onboard new users over several days | Entry on signup event → Wait 1 day → Activate email platform → Wait 3 days → Activate CRM |
| Re-engage inactive customers        | Entry on inactivity audience → Wait 2 days → Segment by tier → Activate per branch        |
| Branch by profile attribute         | Segment node splits contacts by country, plan, or status                                  |
| Wait for a meaningful event         | Pause Until a purchase event → continue or fall through on timeout                        |
| Stop once a contact converts        | Exit rule on `status = converted` removes contacts mid-flow                               |

### How a Journey works

Every Journey follows the same high-level model:

1. Contacts enter through the **Start** step when they match your entry rules.
2. They move through steps — Wait, Segment, Pause Until, Activate.
3. They can leave early if they match one of your **exit rules**.
4. They finish when they reach the end of a path or a Stop node.

### When to use a Journey

Use a Journey when **timing and sequence matter**.

Examples:

* Welcome series with delays between activations
* Re-engagement flow that branches by customer status
* Post-purchase flow that waits for a follow-up event before continuing

### When not to use a Journey

Do not use a Journey when you only need a static audience or a single activation with no follow-up logic. In those cases, a Segment or a one-time activation is simpler and easier to maintain.

***

## Journey Lifecycle

A Journey moves through three working states:

| State      | Description                                                                            |
| ---------- | -------------------------------------------------------------------------------------- |
| **Draft**  | Working state for designing and editing. The Journey does not run.                     |
| **Active** | The Journey is live, accepts new contacts, and runs on its configured schedule.        |
| **Paused** | Progression is temporarily stopped. Use this to review or prepare a controlled change. |

***

## Journey Anatomy

The builder canvas is the visual map of your Journey. Each box is a step. Connections between boxes define the order that contacts follow.

Every Journey starts with a single **Start** step and then expands into the rest of the flow.

### Step types

| Step            | What it does                                                                             |
| --------------- | ---------------------------------------------------------------------------------------- |
| **Start**       | Defines entry rules and the Allow Journey Repeat setting. Every Journey has exactly one. |
| **Wait**        | Delays progression for a fixed duration or until a chosen weekday and time.              |
| **Segment**     | Splits contacts into branches based on a profile field value.                            |
| **Pause Until** | Blocks a contact until a condition is met or a timeout is reached. Creates two paths.    |
| **Activate**    | Activates one or more destinations for contacts at that point in the flow.               |
| **Stop**        | Explicitly ends a branch. Terminal node with no outgoing edges.                          |

### Rules outside the canvas

| Rule type       | Scope                        | When it applies                                      |
| --------------- | ---------------------------- | ---------------------------------------------------- |
| **Entry rules** | Configured on the Start step | Determines who is allowed to enter the Journey       |
| **Exit rules**  | Apply to the whole Journey   | Removes contacts early when a condition becomes true |

<figure><img src="/files/YaYOlindE2gt8XGFbP6C" alt="Journey builder canvas showing a multi-step flow with Start, Wait, Segment, Activate, and Stop nodes"><figcaption><p>The Journey builder canvas — each node is a step, connected in the order contacts follow.</p></figcaption></figure>

### Reading a Journey from left to right

1. Start with the entry rules — who enters and under what conditions.
2. Check the first delay or decision point.
3. Review each branch separately.
4. Look at every Activate step to understand what gets activated.
5. Confirm where each branch stops.
6. Review exit rules last — they can interrupt any active path.

***

## Getting Started

### Create Your First Journey

This guide walks through a simple first Journey that is easy to validate and safe to launch.

**Goal:** Build a basic lifecycle flow with one Start step, one Wait step, one Activate step, one Stop step, and optional exit rules.

**Before you begin**, make sure you have:

* Access to a Customer Hub
* At least one audience or entry condition you can use
* At least one destination available for Activate
* Permission to publish, or a reviewer who can approve the launch

**Step-by-step:**

1. Create the Journey draft
2. Configure the Start step and add your entry rules
3. Add a Wait step after Start
4. Add an Activate step after the Wait
5. Add a Stop step after Activate
6. Add exit rules if needed
7. Review the publish checklist
8. Publish the Journey
9. Run and monitor

**Recommended first pattern:**

For most teams, this is the safest first shape:

```
Start → Wait → Activate → Stop
```

Then expand to Segment or Pause Until only after the simple version behaves correctly.

***

## Journey Concepts

### Entry Rules

Entry rules define who enters the Journey. If you configure multiple rules, the Journey uses an operator:

* **OR** — a contact enters if any rule matches
* **AND** — a contact enters only if all rules match

**Available entry rule types:**

| Type             | Use when                                                                           |
| ---------------- | ---------------------------------------------------------------------------------- |
| Audience entry   | The contact should enter because they belong to a specific DinMo audience          |
| Event occurrence | The contact should enter because a tracked event happened (purchase, signup, etc.) |

**Limits:** up to 10 entry rules per Journey. At least one valid rule required before publishing. Entry rules are locked while the Journey is active.

**Allow Journey Repeat** lets a contact re-enter the Journey after completing or exiting it. Use only when re-entry is a deliberate part of the lifecycle.

### Exit Rules

Exit rules define when a contact should leave the Journey early. They apply across the entire Journey and are evaluated continuously.

**Available exit rule types:**

| Type           | Use when                                                            |
| -------------- | ------------------------------------------------------------------- |
| Profile fields | A profile attribute matches a condition (e.g. `status = converted`) |
| Event table    | A tracked event happened (e.g. cancellation event)                  |

**Operator behavior:** OR means any matching rule can remove the contact. AND means all configured rules must match.

**Limits:** up to 10 exit rules. Exit rules are locked while the Journey is active.

### Wait

Wait pauses the contact for a fixed period of time or until a specific weekday and time.

**Wait modes:**

| Mode      | Description                                      | Example                          |
| --------- | ------------------------------------------------ | -------------------------------- |
| Duration  | Choose an amount and a unit (hours, days, weeks) | Wait 2 days                      |
| Until day | Choose a weekday and a time                      | Wait until next Tuesday at 09:00 |

**Constraints:** duration must be at least 1 unit and cannot exceed 1 year (365 days).

### Segment

Segment splits the Journey into branches based on a profile field. Each group of values creates one branch. Contacts that match no group take the implicit **other** branch.

**Common use cases:** branch by country, plan or tier, lifecycle status.

**Constraints:** up to 10 groups, group names must be unique, overlapping values create ambiguity.

### Pause Until

Pause Until blocks a contact until a condition is met or a timeout is reached. It creates two possible paths:

1. **Condition met** — contact continues immediately when the condition is satisfied
2. **Timeout** — contact falls through to the fallback path after the maximum duration

**Condition sources:** profile field changes, or event occurrences.

**Constraints:** timeout cannot exceed 365 days. If no timeout is set, the wait may be indefinite.

### Activate

Activate activates one or more destinations. This is the step that sends contacts out of DinMo to the destinations selected for that node.

**Configuration rules:** at least one destination is required. The same destination can appear in multiple Activate steps.

### Stop

Stop explicitly ends a branch of the Journey. A Stop node is terminal — it has no outgoing edges. Stop improves readability by making intended branch endings visible in the canvas.

***

## Monitoring and Troubleshooting

### Run History

Run history is the main operational view for a live Journey. Check it:

* After publishing a Journey
* After running a Journey manually
* Before resuming a paused Journey
* When business results look different from expectations

### Common Validation Issues

Validation prevents invalid or risky configurations from being published.

**Errors block publishing:**

* Missing entry rule
* Missing destination on Activate
* Incomplete Segment configuration
* Incomplete Pause Until configuration
* Invalid Wait configuration

**Warnings highlight risk but do not block:**

* Immediate activation after Start
* No timeout on Pause Until
* Repeat entry without an early delay

***

## Best Practices

### Designing Safe Journeys

* Keep the entry logic simple — start with one clear rule
* Add a Wait before the first Activate unless immediate activation is deliberate
* Use exit rules so it is always clear how contacts leave
* Avoid branching unless the downstream paths are meaningfully different
* If the flow is hard to explain in one sentence, it is probably too complex

### Wait vs Pause Until at a glance

|               | Wait                           | Pause Until                                     |
| ------------- | ------------------------------ | ----------------------------------------------- |
| **Use when**  | Delay is time-based            | Delay depends on a condition                    |
| **Trigger**   | Elapsed time                   | Profile field change or event                   |
| **Paths out** | One — continues after duration | Two — condition met, or timeout                 |
| **Example**   | Wait 2 days after signup       | Wait until purchase event, timeout after 7 days |

***

## Reference

### Glossary

| Term                     | Definition                                                                             |
| ------------------------ | -------------------------------------------------------------------------------------- |
| **Active**               | The Journey is live and can run                                                        |
| **Allow Journey Repeat** | Setting that lets a contact re-enter the Journey after completing or exiting it        |
| **Draft**                | The editable working state of a Journey                                                |
| **Entry rule**           | Condition that determines whether a contact can enter the Journey                      |
| **Exit rule**            | Condition that removes a contact from the Journey early                                |
| **Pause Until**          | Step that waits for a condition or a timeout before continuing                         |
| **Run history**          | Operational record of Journey executions                                               |
| **Segment**              | Step that branches contacts based on a profile field value                             |
| **Activate**             | Step that activates one or more destinations                                           |
| **Stop**                 | Terminal step that explicitly ends a branch                                            |
| **Wait**                 | Step that delays progression for a fixed duration or until a specific weekday and time |

***

## Ready to get started?

Book a demo and we will walk through the best way to launch your first DinMo use case.

[Book a demo](https://www.dinmo.com/contact/)

## Need help?

Our team is here to help with setup, modeling, activation, and troubleshooting.

[Contact us](mailto:hello@dinmo.com?subject=Docs%20help)

## Feature requests?

Tell us which connector, workflow, or improvement would make DinMo more useful for your team.

[Request a feature](mailto:hello@dinmo.com?subject=Feature%20request)

[Privacy Policy](https://www.dinmo.com/legals/privacy/) | [Terms of Service](https://www.dinmo.com/terms-of-service/)


---

# 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/journey.md?ask=<question>
```

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.