Roles and permissions

In the portal: You pick the role on an Invitations record. Settings, then Roles, lists what each one holds.

What it is

There are four roles, and that is the whole list: Participant, Coach, Admin and Sales. A role decides what a person can reach inside one tenancy.

You choose one of the four when you invite somebody. The four are fixed, and so is what each one is allowed to do, so the access model is the same in every tenancy and cannot drift over time. The Roles page in the portal shows the four and the permissions on each.

A role applies to one tenancy. The same person can hold Admin in one and Sales in another, and the two say nothing about each other. The four themselves are the same everywhere, so access means the same thing for every customer. If you need something the four do not cover, talk to us: that is a platform change rather than a setting.

The short answer

Role	Which participant records it can read	What it is for
Participant	Their own, and no other	The person using the app
Coach	Only the participants actively assigned to them	Coaching staff
Admin	Every participant in the tenancy	Running the tenancy
Sales	None	Fetching sign-up links

A role grants what it is listed as granting and nothing else, and the denials are written down rather than implied. Sales is the clearest case: three reads, a named list of what it cannot reach, and a test in the platform that fails if anybody ever widens the role. So a seat can be handed to somebody who should never see a participant record, and the platform holds that line for you.

Everything except Participant is a portal login. Coach, Admin and Sales can all sign in to the portal. Participant is the only role that is purely the app. That is why the portal asks you to type the role name in capitals before it sends any invitation other than a Participant one.

The confirmation panel names participant health records for every role except Participant. Read it as the prompt to stop and check the role you picked. What each role reaches is the rest of this page, and Sales reaches no participant record at all.

Everything below is that table with the detail filled in.

Participant

The app role. It holds none of the portal's reads, so a participant login reaches the app and nothing else.

Reads: their own profile, their own health readings, their own screening results, their own chats and coaching messages, their own journeys and deliveries, the home surfaces, and the journey catalogue. It can also export its own data.

Writes: its own answers, its own health readings, its own chat messages, and its own profile.

Cannot reach any other participant, by any route.

Coach

Coaching staff. Signs in to the portal and sees a roster, not a tenancy.

Reads participant records only for the participants actively assigned to them. That scoping is the important part of this role. It is checked on every single participant record, not just applied by hiding a menu item, so a coach who is assigned to nobody sees nobody.

For their own participants a coach reads messages, health readings, screening results, chats, tasks, journeys and deliveries.

Reads the content catalogue without being able to change it: atoms, sequences, journeys, home surfaces, the media library, cohorts, tags, groups and extras. It also reads reports.

Writes: coaching messages, coaching interventions, tasks, hiding a message in a chat, managing who is in a chat, and assigning, updating or cancelling a participant's journeys and deliveries.

Cannot: author or edit content, change any tenancy setting, invite anybody, or read a participant who is not assigned to them.

Admin

Holds every permission the platform defines. There is nothing in a tenancy an admin cannot read or change: every participant record, all content, all settings, invitations, keys, the audit log, and import and export.

One permission is worth naming on its own, because it is what makes Admin different in kind rather than in degree. Admin holds the permission that lifts the coach scoping, so an admin reads every participant in the tenancy without being assigned to a single one.

That is the reason Standing up a tenancy opens the way it does. Creating a tenancy grants an Admin place in it, so whoever creates a tenancy can read every participant record in it.

Admin is the full reach role, so give it only to the people who should read every participant record in the tenancy. For anybody who only fetches sign-up links, use Sales. For anybody who needs a named roster, use Coach. Between them they cover most of the work without granting reach across the tenancy.

Sales

Three reads, and nothing else in the entire platform:

• the tenancies this person has been invited into
• the cohorts inside those tenancies
• the names of the tiers, so the tenancy list can draw its Tier column

That is the complete grant. It buys one useful thing: a salesperson can look up a company and copy its sign-up link, without being able to see a single participant.

Named denials, each one checked by a test that fails if the role is ever widened: participant records, identities, health readings, screening results, chats, coaching messages, chat with the assistant, tasks, progress and data export. The denial holds inside the salesperson's own tenancy, so being a member of a tenancy grants nothing by itself.

Sales cannot write anything, including the cohorts and tenancies it can read. It cannot rename a tenancy and it cannot create one.

In the portal, a person signed in at Sales sees a much shorter sidebar than an admin does. Menu items disappear when the role behind them is missing, so the sidebar shows only what that person can actually do.

How the two layers work

Access is decided twice, and it is worth knowing which layer answers which question.

Layer one is the permission set. It decides whether a whole area opens at all: invitations, journeys, settings, reports. This is what makes the sidebar shorter for a coach than for an admin.

Layer two runs on participant records only. Even with the permission to read participants, a request for one particular person is allowed only if the caller is that person, is a coach actively assigned to them, or holds the admin-wide permission. This is why a coach and an admin hold the same permission and see different rosters.

A person's permissions are worked out when they sign in and again when their session refreshes, so plan a role change to take effect at their next sign-in.

Access is decided by role, not by tier. A tier says which level of the product a customer is on, which is a commercial question. What a person can read and change is their role, which is the two layers above. Set the tier for the level and the role for the access. What a tier includes is agreed with us: see Standing up a tenancy.

What you can now do

Choose the role on an invitation knowing exactly what it opens, which is the one decision on this page that is easier to get right than to fix.

Usually that is one Admin for whoever runs the tenancy, Coach for anybody who needs a named roster, and Sales for anybody who only fetches sign-up links. Nobody has to be given more reach than their job needs, because Sales exists precisely so that fetching a link is not an access decision.

Standing up a tenancy has the runbook for sending that first invitation.