Channels

In the portal: Journeys. All three channels are actions on a node.

What it is

Three channels reach a participant when the app is shut. A push notification on their phone, an email, and a text message.

Text messages are the newest of the three, and they are switched on per tenancy. See Text messages below.

One more thing looks like a channel and is not. In-app chat reaches a participant who already has the app open, or who opens it after a push tells them to. Chat is a place, not a way of reaching somebody.

What each channel carries

	Push	Email	Text message
What arrives	A short lock-screen alert: a title, one line of body, and a place the tap lands.	A full formatted message.	Plain text, whatever you write.
How much content it can carry	Almost none, on purpose. A push never carries message text, a health value, or anything about the person.	Whatever you write.	Whatever you write, and it leaves the platform in the clear, so treat it as a postcard.
Who it can reach	A participant on a phone that has the app installed and notifications allowed.	Anybody with an email address on the tenancy.	A participant with a mobile number on file who has explicitly agreed to texts.
What sets it off	A coach assigning something, a journey reaching a node, or a new chat message.	Three account events, plus a journey reaching a node.	A journey reaching a node. Nothing else.
What you can style	The title and body of a journey notify action. The other alerts carry copy set in the app.	Subject, body, sender name and sender address, per template.	The words, which are all yours.

A push reaches a participant once they have signed in on their phone and allowed notifications. Until then, email is the channel that reaches them, which is why an invitation is an email and not a push.

Write a journey email exactly as it should read. The templated emails substitute {{tag}} values. The journey action sends the subject and the body exactly as you typed them. See Email for the detail.

When you would use each

A worked example. A tenancy runs a six week wellbeing course. On day one the participant needs an invitation with a link that gets them into the app, so that is email. On day four the journey branches and adds a breathing practice, and the participant should know something new is waiting, so that is push. On day five the coach reads a check-in and replies in chat, and the participant gets a push telling them a message is waiting, with the text itself only visible once they open the app.

The rule underneath that: email is how somebody gets in, push is how somebody gets back.

What a schedule does

A schedule puts an item on the home screen. Announcing it is a separate step. A delivery scheduled for every weekday at 08:00 appears on the participant's home screen on those days. Anything you want announced at a particular moment is a notify action on a journey node.

The three cadences. A delivery's schedule is one of three.

Cadence	What it does	Fields
once	A single occurrence. Can still carry a start and an end, so it can appear later and expire.	none
weekly	Recurs every week, on the weekdays you choose.	days, times
custom	Recurs every N of a period. The period is hours, days or weeks.	every, period, days, times

• days takes any of MO, TU, WE, TH, FR, SA, SU. It applies on weekly, and on custom when the period is weeks.
• times takes 24 hour clock values such as 08:00. Each one becomes its own occurrence, so a twice daily check-in is two answers rather than one. It is ignored when the period is hours. Both occurrences are answerable all day, and times is what tells a morning entry from an evening one in the record.
• every is a whole number from 1 up, and it defaults to 1.

Every schedule also carries a start and an end, and both are always present.

Bound	Options
start	immediately, after N days or weeks or months, or at a fixed date and time
end	never, after N days or weeks or months, after N answers, or at a fixed date and time

Cadences count in hours, days and weeks. To repeat roughly monthly, use custom every 4 weeks, and expect it to drift against the calendar rather than land on a date. The start and end offsets accept months, which moves the first and last occurrence without changing the cadence. If a programme needs a fixed date in the month, talk to us before the content is written.

Times are the participant's own clock. A schedule is written as a local wall-clock time with no timezone on it. 09:00 means 09:00 wherever that participant is, and it follows them when they travel.

When a push goes out is decided by what you schedule. A notify action fires the moment its node runs, and a coach's message reaches the phone as they send it. So the send time is yours to choose: put notify actions at the times you want people reached, and agree with your coaches when they message.

Quiet hours

Quiet hours is how you stop the platform waking somebody. A tenancy can set a window in which nothing lights up a participant's phone. It is the notifications.quiet_hours row under Settings, then Configurations, and it holds a start and an end on a 24 hour clock:

{ "start": "21:00", "end": "07:00" }

Every tenancy has the row, and it starts empty, which means no window. Nothing about your notification timing changes until somebody sets one.

The window is read in the participant's own clock, not yours. A tenancy with people in two countries quietens each of them overnight where they are. A window may run across midnight, which is the usual shape. A start equal to its end is read as no window, since it could mean either nothing or the whole day.

Inside the window, a chat message waits and an alert is thrown away.

What lands inside the window	What happens	Why
A chat message, from a coach or from a journey	Held, and delivered when the window closes	It still matters in the morning
The two assignment alerts, and a notify action	Not sent	The thing itself is on the home screen whenever they next look

A notify action timed inside quiet hours does not arrive later. The node still runs, everything it created is waiting on the home screen, and the participant finds it when they next open the app. Where the announcement itself is the point, gate the node so it runs in waking hours.

Participants manage notifications for the app in their phone's own settings, the same as any other app.

The app reminds a participant on its own when something is waiting. Both phones show a local reminder reading "Check in with your journey", then "You have activities waiting. Tap to see today's recommendations."

The time comes from your schedule. It lands at the time of day the schedule was written for, in the participant's own clock, so an item set for 18:00 reminds at 18:00. A schedule that names no time falls back to 09:00. Somebody with nothing waiting gets no reminder at all, so the words are true whenever they appear.

The phone re-points it on every sync, so a schedule you change reaches them the next time the app syncs rather than the next day.

It is a general prompt to open the app, and deliberately so: it fires only when something is actually waiting, so it never nags somebody who is up to date. Anything you want announced at a particular moment, in your own words, is a notify action on a journey node.

Text messages

A journey can send a text. Behind it sits a supplier connection, encrypted credentials, an opt-in consent check, delivery status coming back, and an audit trail.

Three things have to be in place before a text goes out, and each one is recorded. The participant needs a mobile number on their record, in full international form. They need to have explicitly agreed to texts, where absent and unknown both count as no, because New Zealand law on unsolicited messages requires people to opt in rather than to opt out. And the message needs a body. If one of the three is missing, the send is skipped and an entry says which one it was.

Text messaging is switched on per tenancy. Confirm it is live for your tenancy before you build a journey that relies on a text arriving, and ask us if you are not sure.

Agreement to texts is a first-class field on the participant, set and withdrawn like any other consent.

*Today: it is stored in a general-purpose field on the participant. It works, and it is not somewhere a coach would think to look.

Next

There are three channels. What you are trying to do nearly always picks one for you: email is how somebody gets in, push is how somebody gets back, and a text message is the one a journey sends when neither will reach them. A schedule puts an item on the home screen, and anything that has to be announced is its own step on a journey node.

Push is the five alerts, and the one of them you write.

Email is the three templates you can rebrand, and the journey email that behaves differently.