Notifications for participants

This page describes what a person taking part in a program actually receives and sees. The companion page on communications and reminders covers the admin side — which messages a program sends and how they’re worded. This one covers the receiving end.

The two things a participant gets

When the program has something to tell someone, that moment can reach them in two ways:

An in-app notification — an entry in their notification list inside the platform, reachable from the bell in the top bar.
An email — the same moment, sent to their inbox.

Most moments can do both. Which ones actually arrive depends on the person’s own settings, described further down.

One thing worth knowing: the in-app record is kept even for people who have chosen email only. This means the notification list doubles as a history of what the program has sent them — someone can always go back and find a message they’ve deleted from their inbox.

What a participant sees in the app

The bell in the top bar shows a count of unread notifications. Opening it shows a short tray of recent items; each one names the kind of moment it is (a session change, a request waiting on them, and so on) and when it arrived, with unread items visually distinct from ones already seen. Selecting an item opens the full notification.

There is also a full notifications page listing everything, filterable by Unread, Read, or All. Opening a notification marks it as read.

New notifications appear without the person needing to reload the page — if someone is looking at the platform when a notification is created for them, it turns up in place.

Two scoping rules shape the list, and both are worth understanding because they explain why a list can look shorter than expected:

It’s scoped to the role the person is currently using. Someone who takes part in more than one capacity — for example receiving support in one program and giving it in another — sees the notifications for whichever role they’re currently switched into, not a merged pile.
It’s scoped to their current organization. Notifications from one organization’s programs don’t appear while the person is working in another’s.

What a participant controls themselves

In their own account settings, a participant can set:

Delivery channel — how a notification reaches them:

In-app only — no emails; everything lands in the notification list.
Email only — emails are sent, and the in-app record is still kept as history.
Both in-app and email — the default.

Frequency — how often:

Immediate — sent as things happen.
Daily digest — instead of an email per event, one email a day gathering up what they haven’t read.
Weekly digest — the same, once a week.
Mute — stop being nudged.

Language — messages are composed in the person’s preferred language, so someone who has set their account to a different language receives the message in that language rather than the program’s default.

These settings can be held globally for a person or specifically for one program, so someone in several programs can be noisy in one and quiet in another.

How digests behave

For someone on a daily or weekly digest, individual moments stop producing their own immediate emails. Instead, the platform gathers what they haven’t read and sends a single summary email — daily digests each day, weekly digests once a week at the start of the week. Digest emails go out in the morning.

Two details that surprise people:

Digests only cover unread items. Anything already read in the app doesn’t get repeated in the email.
If there’s nothing unread, no digest is sent. A quiet week produces no email rather than an empty one.

In-app notifications are unaffected — they keep arriving as they happen regardless of the digest setting.

What Mute does and doesn’t do

Mute means “stop nudging me”, not “let something important pass me by silently”. A small, deliberately narrow set of time-critical moments still reaches a muted person in the app, because each one either changed their calendar or has someone else waiting on them:

A session was cancelled or rescheduled.
A two-party agreement step is waiting on their response — either they need to review something, or something they sent back needs revising.
A match offer is on the table or about to expire — a time-boxed offer or selection window where not acting means losing it.
A 360 feedback request is pending and its response window is closing.

Outcome-only messages don’t qualify — being told something was approved when nothing is expected of you is exactly what Mute is for.

For email, Mute is absolute: a muted person receives no emails, including for the moments above. Those arrive in the app only.

What an admin can influence

Most of what an admin controls is covered in the communications and reminders page: which moments a program messages people about at all, the wording, the branding, the sender identity, and which roles are in scope. Three things are worth calling out here because they’re specifically about a participant’s own experience:

Program defaults. A program can set default notification preferences for its participants. These apply to someone who has never set their own — once a person has saved their preferences, their choice wins. Changing a program default doesn’t overwrite what participants have already chosen for themselves.
Turning a moment off. Where a message type is switched off for a program or organization, participants simply don’t receive it. It stays quiet on both channels.
Membership decides delivery. A person receives a program’s notifications because they’re an active member of that program (and, where relevant, that cohort). Someone whose participation has ended stops receiving them.

An admin cannot mute or unmute an individual on their behalf — channel, frequency, and language are the participant’s own choices.

Why someone might not have got a message

When a participant says they didn’t receive something, the usual explanations, in rough order of likelihood:

They’re on a digest. The email is coming, just batched — and only if the item is still unread.
Their channel is in-app only. It’s in their notification list; there was never going to be an email.
They’re muted. Unless it’s one of the critical moments above, nothing was sent.
They already read it in the app. A read item won’t reappear in a digest.
They’re looking under the wrong role or organization. The list is scoped to whichever they’re currently in.
The message type is switched off for the program, or their membership isn’t active.
Their email address stopped accepting mail. Where delivery to an address has been shut off, in-app notifications carry on regardless — which is why the in-app list is the reliable place to check what was actually sent.