Journeys

What a Journey Is

A journey is a time-based, multi-step programme run over any datastore: an onboarding sequence, a tenancy sign-up programme, a course of reminders, a re-engagement campaign, a supervision cycle.

Where to find it

Architect Panel → Automation:

• Journey Manager — the console — build, run and monitor journeys
• Journeys — the journey records themselves
• Workflow Builder — the steps a journey is made of

The steps are workflow nodes

The hard part of any journey engine is the durable delay — "wait 30 days, then check they still qualify, then send" — surviving restarts with nothing held in memory.

The platform already had that: the workflow wait node and the task that resumes it. So a journey's steps are workflow nodes, and the journey engine owns only what a workflow does not know.

The practical consequence is that everything you already know about the Workflow Builder applies. A journey step can send a message, update a record, create a task, call a function, branch on a condition — because it is a workflow.

What the journey adds

• Who enters — the scan that finds qualifying records and enrols them.
• Whether they may enter — the re-entry policy, checked against the member ledger.
• Where to send — which column holds the address, per channel.
• When to stop — the goal and the exit criteria.
• How often — frequency capping.
• When not to send — quiet hours, which defer rather than drop.

Frequency capping is per address, not per record

This distinction matters and is easy to miss. If the same person appears on two records — a tenancy and a repair, say, or two applications — capping per record would let them receive the programme twice over.

Capping per address means the person receives it once, which is what they experience and what they will complain about if you get it wrong.

Enrolment cannot happen twice

Two rule hooks firing, a retried write, or a manual run on top of an event-driven one all produce a second enrolment — and for a journey, a second enrolment is a person receiving the same programme twice.

The engine prevents this with a uniqueness constraint in the database rather than by checking first and then writing. A check-then-act would lose exactly the race it exists to prevent, and the failure would be intermittent and very hard to reproduce.

When to use a journey rather than a workflow

Use a plain workflow when something happens to one record because of an event on it. Use a journey when a population should go through a programme over time, and you need entry rules, capping and exits.

Worked example

A housing provider runs a new-tenancy programme. Anyone whose tenancy start date was yesterday enters. Day 1 a welcome message; day 7 a check-in; day 30 a satisfaction request; day 90 a tenancy review task for the officer. A tenant who reports a repair before day 30 exits early — the goal was a settled tenancy, and somebody engaging with the service has met it.

Recommendations

• Design the exit before the steps. A journey with no exit criteria keeps sending to people who no longer need it.
• Cap frequency before the first live run, not after the first complaint.
• Start with a small entry scan and widen once you have watched a cohort through.
• Use quiet hours for anything sending to the public.

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.