Sequences

In the portal: Sequences.

What it is

A sequence is the thing you write. It is an ordered set of pages, and each page holds one or more atoms, which are the individual screens and questions.

A sequence is not on anybody's phone. It sits in your library until a journey or a coach hands a copy of it to one participant. That handover is a delivery, and the delivery is what appears on the home screen.

The practical consequence is worth holding on to. You write a sequence once. It can be delivered to a thousand people, on different days, with different behaviour each time, and every one of those deliveries points back at the same sequence. Change the words in the sequence and every future delivery carries the change.

What it looks like

One card built a piece at a time. Switch any piece off, answer the question the other way, or change who is looking.

To the participant a sequence is a screen with the sequence's name across the top, one page of content at a time, and a button at the bottom right that moves forward.

• If the sequence has more than one visible page, a thin progress bar sits above the content. With one page there is no bar, and the space it would take is held blank so the layout never jumps when a conditional page appears.
• The page's own title, if it has one, is the first line of the page.
• The forward button shows the page's nextButtonLabel when one is set. With no label it shows an arrow, and a tick on the last page.
• A back arrow appears from page two onward.
• Close sits in the top corner, unless closable is off on the delivery.

When you would use one

You create a sequence whenever a participant needs to read something or answer something. Every piece of participant-facing content in the product is a sequence.

A worked example. A sample tenancy running a six week sleep course wants a weekly check-in: one page explaining why it is being asked, then one page with four questions, then a closing page that reflects the answer back. That is one sequence with three pages. It is delivered every Monday for six weeks, which is one delivery carrying a weekly schedule, not six sequences.

You do not create a second sequence to say the same thing to a different group. An atom can carry its own condition, so one card can say different things to different people. Two sequences means two sets of words to keep in step.

The controls

What it says and shows.

Setting	What it accepts	Default	What changes on screen
code	capitals, numbers and underscores, starting with a letter, up to 128 characters	none, required	Nothing. It is the name you refer to it by in an import file, it is unique inside your tenancy, and it is fixed once created. A repeat returns sequence_exists.
name	1 to 200 characters	none, required	The title across the top of the run screen, and the item's title on the home screen.
description	up to 2000 characters	empty	The line under the title on the home item.
startButtonLabel	up to 200 characters	empty	The single control that decides whether a home item gets a start button. Set it and the item shows that button. Leave it empty and the item shows the automatic to-do ring instead. The button comes from this field alone, so this is the whole answer when somebody asks why one card has one and another does not.
assetId	the id of a public, ready asset	none	The item's cover picture on the home screen. It is not shown inside the run.
pages	at least one page, each with at least one atom	none, required	The content. An empty page list, or any page with no atoms, is refused as sequence_incomplete on every write, not just on publish, so build each page with its atoms in one go.
scoring	a strategy and optional bands	none	Whether a submission produces a number. See Questionnaires and scoring.

Where it goes and who can start it.

Setting	What it accepts	Default	What it means
defaultSurfaceId	the id of a surface	none	Which surface a delivery lands in when the assignment does not name one. With neither, the item falls through to the journey, coach and to-do templates in that order.
enrolment	prescribed, self	prescribed	prescribed means only staff or a journey can hand it out. self means a participant can start it themselves from Explore. A participant trying to self-start a prescribed sequence is refused with sequence_not_self_enrollable.
tracking	tracked, untracked	tracked	Whether submitted answers show on the participant's Progress tab. It defaults to on, so anything you build is visible to the participant until you say otherwise.
status	draft, published, archived	draft	See publishing below.

The five defaults, and how they flow down

These five are the reason the page exists. They are defaults on the sequence that get copied onto a delivery at the moment it is created. They are not a live link.

Setting	Accepts	Default	What it governs
defaultPersistent	true or false	false	Whether a submitted item stays on the home screen with a tick, or leaves. False means it vanishes once submitted.
defaultUnscheduledSubmission	true or false	false	Whether an answer can be added outside the schedule. It has nothing to do with recurrence: recurrence is the schedule's job.
defaultRevisable	true or false	true	Whether a submitted answer can be changed afterwards.
defaultClosable	true or false	true	Whether the participant can back out without submitting. False is the blocking consent screen, which has no Close until it has been submitted.
defaultDismissable	true or false	false	Whether the participant is offered a way to hide the item.

Copied, not linked. When a delivery is made, the platform takes whichever of these the assignment did not set and copies the sequence's value into the delivery. From that moment the delivery holds its own values, so somebody halfway through keeps the behaviour they were given. Changing defaultPersistent on the sequence tomorrow reaches the deliveries made after the change.

Anything assigning a delivery can override any of the five for that one person. So two people can hold the same sequence with opposite behaviour, and when something behaves unexpectedly for one person, look at their delivery before you look at the sequence.

Set defaultPersistent: true on anything a participant may want to read twice. With false the item leaves the home screen once it is submitted, which is what you want for one step in a flow and not for a card worth going back to.

Publishing, and what each state does

A sequence is in one of three states. Only one of them reaches a participant.

Status	Can be delivered	Visible to whom	What it is for
draft	no	only people who can edit content	Work in progress.
published	yes	everyone	Live.
archived	no new deliveries	everyone	Retired. Everything already delivered keeps working.

Only a published sequence can be delivered. An assignment of a draft is refused with sequence_not_published and the message "Only a published sequence can be delivered." That applies to a journey handing it out, a coach assigning it, and a participant starting it from Explore.

Editing a published sequence in the portal puts it back to draft. No edit reaches a participant until somebody publishes it, so a half finished change cannot go live on its own. Publishing is a separate button, so publish again once the change is ready. Existing deliveries are untouched either way.

Archive rather than delete. An archived sequence still resolves, so anybody mid-course finishes normally, and nothing new is handed out. A delete is refused with sequence_in_use where a journey references the sequence, and the message tells you to archive it instead. Archive is the operation you want in almost every case.

How it renders

A page with nothing visible on it is skipped, not shown blank. Every page and every atom can carry a condition. The run works out which atoms are visible right now, drops any page left with none, and renumbers. So a sequence written as five pages can be a two page sequence for one participant.

Leave one unconditional atom on any page that carries conditional ones. Visibility is worked out against state that has to be on the device already, so the unconditional atom is what keeps the page saying something.

The progress bar counts visible pages, not authored pages. Someone who skips three conditional pages sees a bar that runs 1 of 2, not 1 of 5.

Answers are checked when you press forward, not as you type. Each atom that fails shows its own message directly under itself.

Going back keeps the answers. The run saves a draft on every page turn and on Close, so closing the app halfway through and coming back later resumes on the page they reached with what they had typed still there.

A correction is a new answer, not an overwrite. Submitted answers are kept in full, so a participant's history is a record of what they said and when.

Worked settings

A one shot welcome. defaultPersistent: false, defaultClosable: true, no schedule, startButtonLabel: "Start". Auto opens at the start of a journey, and the item disappears from the home screen once submitted.

A weekly check-in. defaultPersistent: true, defaultUnscheduledSubmission: false, defaultRevisable: true, a weekly schedule on the delivery. It shows Done for the rest of the day and comes back fresh on the next due day.

A consent screen. defaultClosable: false, defaultPersistent: true, defaultRevisable: false. It opens full screen with no way out until it has been answered, and the answer cannot be changed afterwards.

A reading card worth keeping. defaultPersistent: true, no start button label, tracking: untracked. It stays on the home screen with a tick so the participant can re-read it, and it does not clutter their Progress tab.

Next

You write a sequence once. It goes to as many people as you like, and a change to the words reaches every future delivery. The five defaults are what let the same content be a blocking consent screen for one participant and a reading card for another, without a second copy of anything.

Atom types is what goes on the pages.

Questionnaires and scoring turns a set of answers into one number a journey can branch on.