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 sets out the access model: the roles, the scoping, and the enforcement that backs them.
The roles
Institution staff hold one of three built-in roles, sized to real jobs rather than a sprawling permission matrix, or a custom role your admins compose from the same permission set:
| Role | Purpose |
|---|---|
| Institution admin | Runs the account: settings, the team, the full audit trail, all cohorts |
| Content editor | Builds the student experience, across the whole institution. No access to students or the inbox. |
| Support responder | Works the inbox and cohort wellbeing for their scope |
Admins are deliberately few. Most staff are responders or editors. Where a job doesn't fit a preset, an admin can define a custom role at Settings → Roles by ticking individual permissions; two capabilities can never be delegated to a custom role (team management, and authorising First Six access), and the database enforces that. (A separate First Six platform-owner role exists for the vendor's own support and operations staff; it is not assignable inside your institution.)
Scope limits visibility
A role says what someone can do; scope says which students they can do it for. Scope is set by cohort, degree, or campus. A responder scoped to one faculty sees that faculty's help requests and wellbeing picture, not the whole institution's.
A responder with no scope set sees every student in the institution. Scope narrows; it is not a switch that has to be turned on before someone can work. Set one for anyone who should only look after part of the institution.
Scope applies to support responders, and to any custom role you narrow. It does not apply to content editors. Content editors write for the whole institution, because "which weeks of the arc is this person allowed to write" turned out not to be a question universities ask, and requiring an answer meant the role arrived switched off. If you do want an editor confined to one degree or campus, build a custom role at Settings → Roles and scope that.
Scope exists to narrow who can read a student's help request and wellbeing picture, and it still does exactly that. It was never a control over student data when applied to content, because a content editor cannot reach a student record at all: the role carries authoring permission and nothing else. Full reach over students is the admin and responder path, and it stays scoped.
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?
Yes. Admins compose custom roles from individual permissions at Settings → Roles, alongside the three presets. Two capabilities are deliberately not delegable to custom roles: managing the team, and authorising First Six access. The database enforces that restriction, not just the interface.
How do we limit a staff member to one campus or faculty?
For a support responder, set their scope to that campus, degree, or cohort. Their entire view (inbox, wellbeing, students) narrows to it. Until you set one they see the whole institution, so this is a step to take, not a default to rely on. For someone who only authors content, build a custom role at Settings → Roles and scope that: the built-in content editor role is institution-wide by design, and carries no access to students either way.
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.