Who can see what
Before First Six goes near student data, someone has to be satisfied that the right people — and only the right people — can see it. This page states the access model plainly: the roles, the scoping, and the enforcement that backs them.
The roles
Staff hold one of three roles, sized to real jobs rather than a sprawling permission matrix:
| Role | Purpose |
|---|---|
| Institution admin | Runs the account: settings, the team, the full audit trail, all cohorts |
| Content editor | Builds the student experience for their scope |
| Support responder | Works the inbox and cohort wellbeing for their scope |
Admins are deliberately few. Most staff are responders or editors.
Scope limits visibility
A role says what someone can do; scope says which students they can do it for. Scope is set by course, degree, campus, or cohort. A responder scoped to one faculty sees that faculty's help requests and wellbeing picture — not the whole institution's.
The combination of a small role set and per-staff scope means access is narrow by default and widened deliberately. There's no "everyone sees everything" setting for ordinary staff; full reach is the admin role, held by a few.
Enforcement is in the database
This isn't only an interface convention. Tenant data carries an institution identifier, and row-level securityRow-level security: database rules that decide which rows a given session may read, enforced by the database itself. enforces isolation at the database layer — so the boundary holds regardless of which screen or query is involved. The full account of tenant isolation is in data residency and tenant isolation.
Accountability
Who did what is recorded in an immutable audit trail, surfaced for admins and packaged for reporting in the audit log and evidence pack. Access without accountability isn't enough for welfare data; both are present.
Common questions
Can we define custom roles or granular permissions?
The model is intentionally three roles plus scope, which keeps access easy to reason about and audit. It maps cleanly to "run it / build it / respond to it" plus "for which students". Bespoke permission schemes are not part of the current model.
How do we limit a staff member to one campus or faculty?
Set their scope to that campus, faculty, course, or cohort. Their entire view — inbox, wellbeing, students — narrows to it.
What stops one institution seeing another's data?
Database-enforced row-level security keyed to the institution identifier. It's the same perimeter that isolates tenants from each other, described in data residency and tenant isolation.
Related
The fastest answer is usually one question away.