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.