Building and Running a Journey
Building a journey is four decisions: who enters, what happens, when they leave, and how often you may contact them.
Where to find it
Architect Panel → Automation:
- Journey Manager — the console
- Journeys — journey definitions
- Tasks — the workflow resume task that advances waits
1. Entry
An entry scan finds qualifying records and enrols them. Entry can be event-driven — something happened to a record — or a periodic scan over criteria.
Be specific. A scan matching "all active customers" enrols everybody on day one, which is almost never what you want and is very visible when it goes wrong.
2. Re-entry policy
Decide whether somebody who has been through before may go again, and under what conditions. Checked against the member ledger, so it holds across restarts and re-runs.
- Never — a one-off programme like onboarding.
- After a period — an annual review cycle.
- Always — rare, and worth justifying.
3. Addresses per channel
A journey step that sends needs to know where. The address column is configured per channel, because the email address and the mobile number are different fields — and on a bespoke datastore they may be called anything.
Records missing an address for the channel a step uses will not receive that step. Decide whether that should skip the step or exit the member, and configure it deliberately rather than discovering it.
4. Goals and exits
A goal is the outcome the journey exists to produce. An exit is any reason to stop early.
Both matter. Without a goal you cannot say whether the journey worked. Without exits you keep contacting people whose circumstances have changed — which is the single most common reason a journey generates complaints.
Quiet hours
Quiet hours defer a send rather than dropping it, so a step scheduled for 2am goes out at a reasonable hour instead of vanishing. Set them for anything reaching the public.
Monitoring
Journey Manager shows members and their states. Two things to watch in the first weeks:
- Members stuck at a step. Usually a missing address or a wait that nothing is resuming — check the workflow resume task is enabled.
- Nobody exiting. Almost always exit criteria that are too narrow.
Test with a cohort of one
Enrol a single test record — ideally your own contact details — and watch it all the way through with short waits before running against a real population. Journeys are slow to fail: a mistake at day 30 is discovered a month after you made it.
Worked example
A college runs a re-engagement journey for learners who have not logged in for 21 days. Entry is a nightly scan. Re-entry is allowed after 90 days. Step one emails; step two, seven days later, texts if still inactive; step three raises a task for a tutor. Logging in at any point is the goal and exits the member immediately.
Recommendations
- Enrol yourself first and run the whole thing with minutes instead of days.
- Check the resume task is enabled before you wonder why nothing advances.
- Write the exit criteria down in plain English before configuring them.
- Review member states weekly for the first month.