Journeys
Journeys in the Marketing area (Acquisition) — route /marketing/journeys.
Journeys lives in the Marketing area of the dashboard, under Acquisition.
At a glance#
| Dashboard route | /marketing/journeys |
| Area | Marketing (marketing) |
| Group | Acquisition |
| Platforms | Available for every app platform. |
What it does#
The visual journey builder: multi-step orchestration over the same runtime as Automations. A journey is a trigger plus an ordered sequence of steps, compiled to a graph, validated on the server, and published as an immutable version.
Four step types:
| Step | Does |
|---|---|
| Delay | Waits a fixed period. |
| Send | Sends a referenced message. |
| Wait for event | Pauses until the user does something (or does not). |
| Branch | Splits the path on a condition. |
Immutable versioning is the important property: publishing creates a new version, and users already in flight continue on the version they entered. A journey cannot change under someone mid-sequence.
When to use it#
When one message is not enough. Onboarding is the canonical case: a welcome, then a wait to see whether the user activated, then a different message depending on the answer. That is a journey and cannot be expressed as an automation.
Use an automation for a single triggered send. Reach for a journey when the second step depends on what happened after the first.
Workflow#
Write the sequence down before building it
Journeys get complicated quickly. A branch you added because it seemed useful is a path you now have to maintain and reason about.
Use wait-for-event rather than a fixed delay where you can
"Wait until they activate, up to three days" is a much better message than "wait three days" — it lets you stop messaging people who already did the thing.
Keep branches shallow
Two branches you understand outperform six you cannot predict. Every branch multiplies the paths you have to verify.
Publish, then watch the first cohort through
Server-side validation catches structural errors. It cannot catch a journey that is structurally valid and a bad experience.
Permissions and prerequisites#
Requires messages to reference and a trigger. Delivery requires the relevant channel configured.
Limits and edge cases#
Published versions are immutable. Editing creates a new version; in-flight users stay on theirs. That means a fix does not reach people already in the journey.
Long waits mean long-lived state. A journey with a fourteen-day wait has users in it for a fortnight, including after you decide to change it.
Wait-for-event needs the event to be reliable. A wait on an event your app sometimes fails to send strands users in the step.
Suppression applies at every send step, not just the first.
Troubleshooting#
Users stuck in a step. A wait-for-event whose event never arrives. Give every wait a timeout path.
Edited a journey and behaviour did not change. In-flight users are on the previous version by design.
Validation fails on publish. The graph is structurally invalid — usually a branch with no path or a step referencing a deleted message.
Where the data comes from#
Served by
Journeys