School-level access control (Trust vs school)
For adminsSchool-level access control
Section titled “School-level access control”A Keystone workspace is the trust. Inside it, schools (academies) are separate units. Most data — tickets, assets, compliance schedules, room bookings, SCR rows, risks, policies — is school-scoped, so a Designated Safeguarding Lead at one academy never sees another’s confidential records, and a trust-IT admin can drill into any single school for compliance reporting.
This page explains:
- The two RBAC tiers (trust admin vs school-pinned)
- How the school switcher behaves for each
- What
restricted_to_school_iddoes - What “trust-level” rows are (and when to use them)
The two tiers
Section titled “The two tiers”Trust admin
Section titled “Trust admin”A trust admin has the admin role and no restricted_to_school_id.
- Sees every school’s data when no school is focused (the masthead chip reads All schools).
- Can use the school switcher in the masthead to scope into a specific academy. Every page reloads filtered to that school.
- Picking All schools from the switcher clears the focus and returns to the trust-wide view.
- Trust-IT, central HR, the trust DPO and the COO are typical trust admins.
School-pinned user
Section titled “School-pinned user”A school-pinned user has restricted_to_school_id set to a single school’s ID.
- Cannot ever see another school’s data — server-side enforcement, not just a UI hide.
- The masthead chip shows their pinned academy with a small lock icon, and the dropdown is disabled. Hovering explains: “You are pinned to
. Contact your trust IT lead to change this.” - DSLs, school office staff, individual headteachers and per-school IT staff are typical pinned users.
A user can be a member of multiple schools (school_user pivot) but still be pinned to one. Membership is “you can be assigned to tickets here”; pinning is “you only see this academy’s records.” The two are separate axes.
How to pin a user
Section titled “How to pin a user”In Identity → Users, edit the user and set Restricted to school. Save. From the user’s next request the chip is locked to that school. Set it back to — to un-pin.
”Trust-level” rows (school_id = NULL)
Section titled “”Trust-level” rows (school_id = NULL)”Some records aren’t pinned to a single school. Examples:
- A trust-wide policy (HR Code of Conduct, applicable everywhere)
- A governor’s SCR row (governors typically aren’t aligned to one academy)
- A central-trust ticket (a network outage that hits every school)
These rows have school_id = NULL. The school scope reads them through to every school’s view — they are visible to a DSL in School A and a DSL in School B equally. That’s intentional: trust-level records are the trust’s, not any one school’s.
When you create a record while no school is in focus (a trust admin who hasn’t picked a school), it stays trust-level (school_id = NULL). When you create one with a school in focus, it gets pinned to that school. The switcher lets a trust admin choose at create time.
What’s school-scoped today
Section titled “What’s school-scoped today”| Module | School-scoped models |
|---|---|
| Helpdesk | Tickets |
| Assets | Asset, Discovery agent, Software license, Stocktake session, Discovered device |
| Estates | Site, Room, Room booking, Compliance schedule, Inspection |
| Governance | Policy, Risk, Governance action |
| Health & Safety | Risk assessment, Checklist |
| SCR | Engagement check, Check requirement |
| People | Person, Engagement |
Catalogues and trust-wide configuration (asset categories, compliance types, SCR check types, policy/risk categories) sit at the workspace level — they’re shared across every academy in the trust.
What changes when a trust admin focuses a school
Section titled “What changes when a trust admin focuses a school”Once a school is focused (chip reads its name in the masthead):
- Every list (tickets, assets, compliance schedules, …) auto-filters to that school + the trust-level rows.
- Every counter / KPI / RAG status reflects that school only.
- Every new record created from that focused session is pinned to that school.
- The chip shows the URN as a quiet sub-line so you can confirm DfE identity at a glance.
Switching back to All schools restores the cross-academy view. The trust-IT lead’s daily flow is: drill into a school for an investigation, switch back for the rollup.
Edge cases
Section titled “Edge cases”- Stale session: if your access to a school is removed while you’re focused on it, the next request silently clears your school context (no 403). The switcher will no longer offer that school.
- Single-school workspaces: if a trust has only one academy, the chip still renders but the dropdown is suppressed (nothing to switch to). The chip is a visual anchor, not a control, in that scenario.
- No-school-yet workspaces: if no schools have been created (early in setup), the chip is hidden until the first one lands.