Deliveries
In the portal: Users, then a participant, to see what they hold. Deliveries are made by a journey or a coach, not created here by hand.
What it is
An item is on a participant's home screen because somebody gave that piece of content to that one person. The record of the giving is called a delivery. One delivery is one sequence handed to one participant.
Home content is always delivered to a named person. There is no tenancy-wide setting that puts an item on everybody's home screen. To give a whole group the same item, put it in a journey they are all on, which is how almost all content arrives, or assign it to each of them.
A surface holds none of it. The surface decides the look and the position. The delivery decides that there is anything to look at.
What it looks like
Two deliveries can sit on the same surface and look nothing like each other, and what decides it is the content, not the surface.
The surface playground lets you move any of these settings and watch the result.
When you would look at this
You look at deliveries when a participant is missing something, or has something they should not have.
A worked example. A tenancy runs a six week wellbeing course. A programme owner opens one participant's record and sees three items on the home screen when the course should be showing four. The missing item is not a surface problem, and changing surface settings will never bring it back. Look for the delivery. If there is no delivery, the journey never reached the node that creates one, or the assign failed. If there is one, its schedule decides whether today is a day it appears.
Three things create a delivery, and there is no fourth.
A journey creates one when a participant reaches a node that carries an assign action. This is how almost all content arrives.
A staff member creates one by assigning a sequence to a participant. The platform stamps that staff member onto the delivery, which is what lets the item show a credit chip and what gives it a surface of its own.
A participant creates one by starting something themselves from Explore, from a sequence you have marked self enrollable or one belonging to a journey they are already on. The platform checks that membership before it enrols them, so Explore stays inside what you have made available.
The controls
Every field on a delivery. The first group decides what is delivered and where.
| Field | What it accepts | Default | What it does |
|---|---|---|---|
sequenceId | the content to deliver | required | Must be published. A draft or an archived sequence is refused with sequence_not_published. |
surfaceId | a surface, or nothing | the sequence's defaultSurfaceId, else nothing | Where the item sits. Leave it empty and the platform picks a surface for you, so a delivery naming no surface never falls off the screen. Which one it picks, and why it matters, is on How surfaces are ordered. |
journeyId | a journey, or nothing | nothing | Which journey this came from. Drives the credit chip and the journey's own surface. |
coachId | a staff member | stamped by the platform | Set automatically when a staff member assigns to somebody else and no journey is named. You cannot set it by hand. |
sortKey | any whole number | 0 | The number a surface sorts its items by. |
autoOpen | true or false | false | Opens the content straight away instead of waiting for a tap. The item still appears on the home screen, so a participant who backs out can find it again. It is a property of the delivery, not of the surface the item sits on. |
schedule | a schedule, or nothing | the sequence's defaultSchedule | When the item is due. Covered on the next page. |
status | active, completed, cancelled, expired | active | Only an active delivery is considered for the home screen. |
Editing a published sequence sends it back to draft, so nobody is ever handed a half-finished edit. Publishing again is a separate button, and new assignments resume the moment you press it. Deliveries that already exist keep working throughout, so finish the edit and publish it when you are ready.
The five behaviour flags
These decide how the item behaves once the participant touches it. Each one falls back to a default the sequence author set, and each falls back again to the value in the last column.
| Flag | What it governs | Sequence default | Falls back to |
|---|---|---|---|
persistent | Whether a submitted item stays on the home screen with a tick, or leaves. | defaultPersistent | false |
revisable | Whether a submitted answer can be changed. A submitted item always reopens either way. This picks read only against editable. | defaultRevisable | true |
closable | Whether the participant can back out of an open capture without submitting. Set it to false and you have a blocking consent screen. | defaultClosable | true |
dismissable | Whether the participant is offered a way to hide the item. | defaultDismissable | false |
unscheduledSubmission | Whether an answer can be added outside the schedule. | defaultUnscheduledSubmission | false |
All five can be changed on a live delivery, and the participant's existing answers are untouched. You do not have to cancel a badly configured item and reassign it.
When an item behaves oddly and the delivery looks untouched, the behaviour came from the sequence. Each flag falls back to the sequence author's default when the assign does not name it, so a journey action that names only the sequence inherits everything the author set.
How it renders
The delivery decides the item's words and picture, not the surface. Its name, its description, its picture and its start button label are all read from the sequence being delivered.
A start button appears when the sequence carries a start button label, and never otherwise. There is no surface control for it. Without a label the item shows the automatic to-do ring instead, and the whole card is tappable either way.
A delivery the participant was given always appears, even before its content
syncs. Until the content reaches the phone the item draws a greyed row reading
Unavailable, with a second line saying it will appear once synced. That row is not
tappable, and it becomes the real item as soon as the sync completes.
One delivery can draw more than one item on the same day. A schedule with two times of day produces two items, each answered and dismissed on its own.
Only an active delivery reaches the home screen. Set the status to
completed, cancelled or expired and the item leaves.
Worked settings
A daily check-in that leaves when it is answered. persistent: false,
revisable: true, dismissable: false, on a weekly schedule. The participant
answers, the item goes, and it comes back tomorrow.
A consent screen the participant cannot skip. closable: false,
persistent: true, autoOpen: true, with no schedule. The capture opens the
moment the app does. There is no way out of it without submitting, and the item
stays visible afterwards as a record.
A piece of reading that stays available. persistent: true,
dismissable: true, revisable: true. It stays on the home screen once opened,
and a participant who does not want it can hide it.
Next
Three things create a delivery and there is no fourth, so "why is this on their screen" and "why is this missing" are both answerable from one record. Every one of the five behaviour flags can be changed on a live delivery without cancelling it and without losing the participant's answers.
What takes an item away is the other end of the same record: the four reasons an item leaves.
Schedules and recurrence is the schedule
field, which decides which days an item is due.