Skip to main content

How a journey works

In the portal: Journeys.

What it is​

A journey is the thing that gives a participant content over time, and decides what they get next based on what they did.

It is a set of steps with rules between them. Each step can hand the participant something, or tag them, or message them, or do nothing at all. Each rule looks at what the participant has done and says whether to move on.

The thing to hold on to is that a journey never draws anything. It creates deliveries, and a delivery is what shows up on the home screen. Change a journey and you change what people are given. Change a surface and you change how it looks.

A journey is also not a schedule, so you almost never want a node per day. If something recurs, that is the delivery's schedule doing the work. A daily check-in for six weeks is one delivery with a weekly schedule and one node, not forty-two nodes. See Schedules and recurrence.

What it looks like​

The same four nodes you will learn to build, watched from the other side. Change her answer with the buttons and play it again to see the other path taken.

A small journey, drawn as a picture. Four steps, three rules.

[ Welcome ]
| they answered the welcome card
v
[ Sleep check ]
| \
| score is 10 or more \ anything else
v v
[ Extra support ] [ Week one ]

Each box is a node. Each arrow is a transition. The words on an arrow are its condition. The things a node hands out when the participant arrives at it are its actions.

When you would use one​

Ana is starting a four week sleep course.

On day one she gets a short welcome card. When she finishes it, the course gives her a sleep questionnaire. Her score decides what happens next: a high score puts her on a supported track with a coach task raised, and everything else puts her on the standard track. From there she gets one piece of reading a week for four weeks, and a daily sleep check-in every morning.

Every one of those decisions is a journey. None of them is a person watching a dashboard, and none of them is scheduled by hand for Ana.

You would not use a journey for a single piece of content that everyone gets on the same day with no follow-up. A coach can assign that in two clicks and nothing needs to branch.

The four parts​

There is nothing else in a journey.

PartSchema nameWhat it does
stepnodeA place the participant can be. Exactly one node is the participant's current position at any moment. Assigning a journey starts the participant at its start node, including somebody who already holds it, so assign it once.
what a step doesactionsRuns the moment the participant arrives at that node, in the order you wrote them. Delivering a sequence is one action type. There are twelve.
a way out of a steptransitionsA one-way arrow to another node.
the rule on the way outconditionWhether that arrow is open. No condition means always open.

A node with no actions is completely legitimate. A step that only routes people is a common and useful shape.

How it runs​

The journey only moves when something happens. It is not a timetable that ticks along on its own. Three things make it look at itself again:

  • the participant submits an answer
  • the app opens, or syncs in the background
  • a waiting period the journey is counting matures while the app is running

When it looks, it starts at the participant's current node and checks that node's arrows in order. The first arrow whose condition is true is the one taken. The participant moves, the new node's actions run immediately, and the check repeats from there. It stops when no arrow is open, or when it reaches an end node.

That last part is why a journey can move several steps at once. If you write three nodes in a row with no conditions between them, a participant passes through all three and their actions all run, in one pass, in one moment.

One submission moves the participant at most one conditional step. When an answer opens an arrow, that answer is spent. The next arrow along cannot read it. This is deliberate, and it is what stops one questionnaire from firing an entire chain of answer-driven branches. Details are on Conditions.

The journey runs on the phone. A waiting step set to mature overnight matures the next time the participant opens the app, not at three in the morning, and content timed for day three arrives on the day they next open the app after day three. Design around the participant's next visit, not around an exact minute.

Give every branching node a way out that can always fire. An arrow with no condition, or an .at exists catch-all written last, is what keeps everybody moving. If every arrow out of a node tests something that can stay false, the participant stays on that node until one of them becomes true. The full rule is on Nodes and transitions.

Retire content by stopping new deliveries, not by deleting it. A delivery that has already gone out stays on the participant's home screen, and deleting the content behind it does not take it back.

Worked example​

Ana's sleep course, written out as nodes.

Node 1, welcome, type start. One action: deliver the welcome sequence, opened in her face rather than left on the home screen. One arrow out, condition "the welcome sequence has been submitted".

Node 2, sleep-check. One action: deliver the sleep questionnaire onto the to-do surface. Two arrows out. The first arrow goes to supported, and it opens when she scores 10 or more. The second goes to week-one, and it opens when she has submitted the questionnaire at all. The first arrow is checked first, because the specific case has to be checked before the general one.

Node 3, supported. Three actions and no delivery at all: raise a task for the coach, tag her as supported, and send her a chat message. One arrow out to week-one, with no condition, so she passes straight through.

Node 4, week-one. One action: deliver this week's reading, and a second action that creates the daily sleep check-in with a schedule of every morning for four weeks. One arrow out to week-two, condition "seven days in this node".

Ana never sees any of this. She sees a card, then a questionnaire, then a piece of reading and a daily check-in.

Next​

Nodes and transitions gives you the structure rules: what a valid journey has to have before it can be published, how arrows are ordered, and what an end node does.