Sectors
Google Workspace for schools and academies
Schools running Google Workspace for Education need student and staff accounts in at least 2 separate org units with different sharing rules, safeguarding alerting configured rather than assumed, and an end-of-year rollover process that graduates, archives and reissues accounts without losing coursework.
| Org units | Separate student, staff and admin trees |
|---|---|
| Student sharing | Restricted to the domain by default |
| Safeguarding | Alerting configured and routed to a named DSL |
| Rollover | Planned in March, executed after results |
| Leaver coursework | Exported or transferred before archive |
| Third-party apps | Allowlisted, never open marketplace access |
Students and staff are different tenants in everything but name
The controls appropriate to a member of staff and to a year-eight student have almost nothing in common. Separate org unit trees let you apply external sharing restrictions, application allowlists, chat availability and drive controls independently, and they make year-group-level policy possible.
Where schools get into trouble is a flat structure with exceptions bolted on. Every exception is a thing somebody has to remember, and staff turnover means it will eventually be forgotten. Structure is more durable than memory.
- Separate org units for staff, students and administration
- Year-group sub-units so policy can differ by age
- External sharing off by default for students, on by exception
- Application allowlist rather than open marketplace access
- Chat and Meet availability set per org unit, not globally
Safeguarding alerting has to be configured and routed
Workspace can surface alerts on concerning activity, but alerts sent to an unmonitored admin mailbox are worse than no alerts, because they create a record that something was flagged and nobody looked. Routing matters as much as configuration.
Alerts should reach a named designated safeguarding lead with a documented response path and a deputy for absence. That routing needs testing at least once a term, in the same spirit as a fire drill, because the failure mode is silent.
The end-of-year rollover
Rollover has four parts: promoting continuing students between year-group units, handling leavers, creating incoming accounts, and reconciling staff changes. It is entirely predictable and yet routinely done in a rush in the last week of August.
The leaver decision should be made in March. Options are export coursework to a personal account, retain the account in an archive unit for a defined period, or suspend and delete after retention. Whichever the school chooses, deciding it in March means August is execution rather than judgement.
Third-party educational applications
Teachers adopt tools quickly, which is good pedagogically and hazardous administratively. Every application authorised with OAuth against student accounts holds whatever scopes it requested, and in an open marketplace configuration nobody is reviewing what those scopes are.
An allowlist with a lightweight approval route is the workable compromise: teachers can request, a named person reviews the scopes, and the answer arrives within a few days. Blanket blocking produces workarounds; blanket permission produces exposure.
What we see that others don't say
The academic-year rollover is the single largest administrative event in a school tenant, and the schools that handle it calmly are the ones that treat leaving students as an archival decision made in March rather than an account deletion done in August.
What this doesn't cover
- We do not provide safeguarding policy or training. We configure the technical alerting to support the policy your DSL owns.
- We do not manage classroom devices or MIS platforms. Chromebook and MDM work is adjacent and quoted separately.
- We do not filter web content. That is a network or endpoint control, not a Workspace configuration.
- Curriculum and pedagogical use of Workspace tools is outside our scope; we handle the tenant, not the teaching.
Questions we get asked
- How should a school structure Google Workspace org units?
- Separate trees for staff, students and administration, with year-group sub-units under students so sharing rules, application access and communication settings can differ by age without per-account exceptions.
- What happens to student accounts at the end of the year?
- Continuing students move between year-group units, and leavers follow a decision made in advance: export coursework, retain in an archive unit for a set period, or suspend and delete after retention.
- Can Google Workspace support safeguarding alerting?
- It can surface alerts on concerning activity, but they must be routed to a named designated safeguarding lead with a deputy and tested each term. An alert reaching an unmonitored mailbox is a liability.
- Should teachers be able to install any Google Workspace add-on?
- No. Use an allowlist with a fast approval route so scopes are reviewed by a named person. Open marketplace access grants unreviewed scopes against student data; blanket blocking just produces workarounds.
How this page is verified
Reviewed by Pearl Lemon Cloud security desk, Workspace security and compliance reviewers. Last checked .
- Org unit policy inheritance, alerting and marketplace allowlist behaviour reflect Google Workspace for Education documentation as of 2026-08-06.
- Rollover practice is drawn from Pearl Lemon Cloud education engagements to 2026-08-06.
- This page describes technical configuration and is not safeguarding advice.
Sources you can check
Related pages
Get the tenant ready before September
We restructure org units, configure and route safeguarding alerting, and build a rollover runbook your team can execute without us.