Journeys

A journey is a multi-step automation that runs continuously. Contacts enter when they match a trigger, flow through a sequence of actions and decisions, and exit when they reach an endpoint or are removed.

Journeys are the core of lifecycle marketing — they replace one-off campaigns with persistent, behaviour-driven flows. Every send inside a journey is routed by journey-driven dispatch, which decides the right channel, the right time, and the right fallback for each contact.

When to use journeys vs campaigns

Rule of thumb: if the flow has waits, branches, or multiple steps, use a journey. If it’s a single message to a segment, use a campaign.

Journey building blocks

Every journey is built from a small set of node types connected by edges on a visual canvas:

Node type values are always lowercase snake_case. Each node has a detailed guide — see the links below. The full canonical list is documented under Graph schema.

Graph shape

Journeys are stored as nodes plus an explicit edges[] array on the graph. Edges carry a label ("true", "false", "timeout", etc.) and optional canvas waypoints — they do not carry branching logic. The decision lives inside the branch node’s config; edges are dumb pointers from a node’s output port to the next node.

The next_nodes[] field on each node is deprecated and always empty — routing is always read from edges[].

How sends actually deliver

A send node names a channel (WhatsApp, SMS, email, in-app, push), but the journey-driven dispatch policy may override it:

• Chat-first — if the contact is mid-conversation on WhatsApp / in-app, the send routes to that thread regardless of the configured channel. Live conversation wins.
• Warm-offer collapse — if an operator has staged a higher-priority message (a CSM outreach, a renewal warning), it rides along with the journey send instead of generating a separate touch.
• Channel fallback — if the configured channel is unreachable (opted out, capped, suppressed), the send falls back through the contact’s preference order.
• Frequency cap — if delivery would exceed the contact’s cap, the send is delayed.
• Cross-campaign suppression — if the contact is in an attached suppression segment, the send is dropped.

You’ll see all of this on the contact timeline for any send — including which rules fired and why.

Journey lifecycle

Draft → Published → Active → Paused → Completed

• Draft — editable on the canvas, not yet accepting contacts
• Published — live, contacts flow through as they match the trigger
• Active — at least one contact is currently in the flow
• Paused — manually paused; contacts in-flight are held at their current step
• Completed — manually ended or all enrolled contacts have exited

You can edit a published journey — Active Reach versions the changes and applies them to new entrants while existing contacts continue on the version they entered.

How contacts flow through

1. A contact matches the trigger (event fired, segment entered, API call, or scheduled date)
2. They enter the journey at the trigger node
3. At each node, the journey engine evaluates the node’s config and moves the contact to the next connected node
4. If a wait node is encountered, the contact pauses until the condition is met
5. If a branch node is encountered, the contact takes the matching path (yes/no, or multi-branch)
6. If a send node is encountered, journey-driven dispatch decides how and where to deliver
7. When the contact reaches an exit node (or no more connected nodes), they leave the journey

A contact can only be in one instance of a journey at a time. If they re-trigger while already inside, the behaviour depends on the journey’s re-entry setting (re-start, ignore, or queue).

Guides