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.

Education tenant structure
Org unitsSeparate student, staff and admin trees
Student sharingRestricted to the domain by default
SafeguardingAlerting configured and routed to a named DSL
RolloverPlanned in March, executed after results
Leaver courseworkExported or transferred before archive
Third-party appsAllowlisted, 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.