Access and permissions

Access and permissions

Two separate questions

The platform answers two different access questions, and they are configured in different places:

• Who can get into the admin app, and which parts of it? This is about administrators — the people who design and run programs.
• What can a participant, coach, or manager see and do inside a program? This is about the people taking part in the program itself.

Both work the same way underneath — someone holds a role, the role carries a set of permissions, and the permission is checked at the moment the action happens — but they are configured independently. Turning something on for administrators does not change what participants see, and vice versa.

This page is about what someone is allowed to do. For what each role is called and how a program chooses which roles it uses, see Roles and terminology.

Permissions are granted, not assumed

Nothing is allowed just because a screen exists. Every protected action and every protected area has its own named permission, and a person can only do it if a permission they hold says so.

The important consequence: if no rule says yes, the answer is no. A person with no roles at all in a program can do nothing there. A permission that has never been granted to a role is denied for that role. This is deliberate — a mistake in configuration results in someone seeing too little, not too much.

Administrator access

The kinds of administrator

An administrator is a person who has been given one or more admin roles. The platform ships with a fixed ladder of admin kinds, each with its own default bundle of permissions:

• Super Admin — a platform-level role held by Sparkus staff, not by customers. It reaches everything, across every customer, including system-level tooling.
• Tenant Admin — full access to everything within their own company: company settings, branding, locations, user attributes, all programs, all people, all reports, the shared tools library, and communications. They do not reach platform or system-level areas.
• Program Admin — full design and operation of the specific programs they are assigned to: program settings, timeline, exercises, matching, forms, language, cohorts, sessions, participants, and demand. They can view and manage users, and view pools, profiles and requests, but do not get company-wide settings, the shared tools library, or communication reports.
• Program Runner — day-to-day operation only, on their assigned programs: cohorts, sessions, participants, and demand. No program design, no reports, no communications.
• Program Reporter — read-only. They can look at their assigned programs and read and export reports, but change nothing.

Company-wide versus program-scoped

The scope of an admin role matters as much as its permissions.

A Tenant Admin is company-wide: their access is not limited to a list of programs. The three program-level kinds — Program Admin, Program Runner, Program Reporter — are assigned per program. If someone should run three programs, they are assigned to those three programs, and the other programs in the company are simply not available to them.

A person can hold more than one admin role. Their permissions are the combination of the bundles they hold.

Turning admin permissions off for a whole company

Beyond the role bundles, a company has its own switch for each admin permission. This is an opt-out, not an opt-in: every permission is considered on for a company unless it has been explicitly switched off. Switching one off removes it for everyone in that company, no matter which admin role they hold — the role bundle and the company switch have to agree before an administrator gets the permission.

This is the right lever when a whole capability isn’t part of a company’s engagement. It is a blunt one: it is not a way to restrict one particular administrator, because it applies to all of them.

Managing who is an administrator

Assigning and revoking admin roles, changing the company-wide permission switches, and reading the access audit log are reserved to Sparkus staff. They are not part of any customer admin bundle. Every assignment, revocation, and switch change is written to an audit log with who did it and when.

Participant-app access

Permissions per role, with allow or deny

Inside a program, permissions cover things like viewing or managing sessions, viewing or managing goals, viewing handshakes, viewing or managing forms, viewing and creating reports, sending messages, and — for managers — seeing a team member’s progress or evaluations.

Each of these is granted to a role as an explicit allow or deny. That default answer — “this role, this permission, allowed or not” — is the baseline the platform falls back to when nothing more specific has been said.

Overrides: cohort beats program beats company

The baseline can be overridden, and the overrides are layered. When the platform evaluates a permission for someone, it looks for the most specific override that applies and stops there:

1. Cohort — an override set for this role in this cohort wins over everything else.
2. Program — if there’s no cohort override, a program-level override for this role applies.
3. Company — if there’s neither, a company-wide override for this role applies.
4. Default — if no override exists at any level, the role’s baseline allow/deny is used.
5. If even that is missing, the answer is no.

Two things follow from this that are worth internalising:

• An override is a full answer, not a nudge. The first level that has something to say decides the outcome — it isn’t combined with the levels below it. A cohort override that says deny wins even if the program and company both say allow, and a cohort override that says allow wins even if the company says deny.
• Absence is not denial. Not having an override at a level doesn’t block anything; it just hands the question down to the next level. To actually take a permission away for a cohort, an explicit deny has to be recorded at that level — leaving it blank means the program or company answer applies.

Because the layers are keyed to a role, an override changes things for everyone holding that role at that level — it is not a way to give one individual different permissions from their peers.

Company administrators inside their own programs

Someone who is the primary administrator of a company holds every participant-app permission for the programs belonging to that company, without needing role grants or overrides. The role-and-override model described above is what governs everyone else.

Seeing another person’s data needs a real relationship

Holding a permission is necessary but, for anything that concerns a specific other person, it is not sufficient. The platform also checks that the viewer actually stands in the right relationship to that person.

• A manager can reach a team member’s progress, self-evaluation, or evaluation data through the direct (and, where configured, skip-level) reporting relationship — not for people outside their line.
• A coach or mentor can reach the sessions, goals, reports, and handshakes of the people they are actually matched with — not of other participants in the same program.
• HRBP access to company-level reporting runs through their HRBP relationship.

Program-wide administrative actions — program settings, cohorts, matching, forms, messaging — are not tied to a per-person relationship; the permission alone governs them.

This second check is why a manager who has been granted a permission still can’t browse the whole program: the permission decides what kind of thing they can do, and the relationship decides whose data they can do it to.

How this relates to menu visibility

A program’s settings include a per-role menu visibility matrix, which shows or hides areas like sessions, reports, or goals for support givers, managers, and HRBP (see Program settings). That is a different lever from permissions, and it’s worth keeping them straight:

• Menu visibility shapes what a role is shown in a program’s navigation.
• Permissions decide what a person is allowed to do, and are enforced when the action runs — not only when the menu is drawn.

They’re best used together and kept consistent. Hiding a menu entry for a role that still holds the underlying permission tidies the navigation but does not remove the ability. Removing the permission is what removes the ability.

When changes take effect

Permission changes are evaluated live rather than baked in when an account is created, so a change to a role bundle, a company switch, or an override applies to what that person can do from then on. An administrator whose access has just changed may need to reload — or in some cases sign out and back in — before the admin app’s navigation catches up with their new permissions.

Things to check when access looks wrong

• Someone sees nothing at all in a program. They most likely hold no role at that scope. Check their enrollment and role assignment first — the permission model can only act on a role that’s actually there.
• A program admin can’t reach a program. Program-level admin roles are assigned per program. Check that they’re assigned to this program, not just to others.
• A permission is off for everyone in the company, whatever their role. Check whether the company-wide switch for that permission has been turned off. That switch overrides all admin role bundles.
• A cohort’s behaviour differs from its program’s. Look for a cohort-level override on that role — it beats the program and company answers.
• A manager or coach has the permission but still can’t see a specific person. They probably aren’t in the required relationship with that person. Permissions and relationships are two separate checks and both must pass.