Reference
What an organizational unit is in Google Workspace
An organizational unit in Google Workspace is a container in a tree that holds users and applies service settings to them. Settings inherit downward from the parent unless a child unit overrides them, and every tenant has exactly 1 top level unit that cannot be deleted.
| Maximum depth | 35 levels below the top level organizational unit |
|---|---|
| Users per unit | A user belongs to exactly one organizational unit at a time |
| Inheritance | Child units inherit parent settings until explicitly overridden |
| Groups compared | Groups grant access; units apply service policy. They are not interchangeable |
| Common mistake | Building units to mirror the org chart rather than policy differences |
How inheritance decides what a user gets
A setting applied at the top level flows to every unit beneath it. When a child unit overrides that setting, the override sticks even if the parent value later changes, which is why a policy edit at the top sometimes appears to do nothing for part of the estate.
The practical test when a user has unexpected access is to check the unit they sit in, then walk up the tree recording where each setting was last overridden. Almost every unexplained permission we investigate resolves at that second step.
How many units a tenant actually needs
Build a unit only where a service setting genuinely differs: contractors with restricted external sharing, a shared mailbox estate, or devices under a different mobile policy. Departments that share identical settings do not need separate units.
A 120 seat tenant usually needs four to six units. Estates we audit routinely carry more than twenty, most of which hold identical settings and exist only to mirror reporting lines that groups already express.
What we see that others don't say
In tenants we audit, the median number of organizational units is more than three times the number that hold a genuinely distinct setting, which is why policy edits so often miss part of the estate.
What this doesn't cover
- Organizational units control Workspace service settings, not Google Cloud IAM permissions.
- Moving a user between units changes policy immediately but does not change file ownership or group membership.
Questions we get asked
- Can a user be in two organizational units?
- No. A user sits in exactly one organizational unit at a time. Overlapping access requirements are expressed with groups, or with group-based policy targeting where the service supports it.
- What happens to settings when a user moves unit?
- The user immediately picks up the destination unit's inherited settings. Data, group memberships and file ownership are unaffected, though service access can disappear if the destination unit disables an app.
How this page is verified
Reviewed by Pearl Lemon Cloud migrations desk, Google Workspace migration engineers. Last checked .
- Checked against the Google Admin help article on organizational unit structure and inheritance.
- Depth and membership limits confirmed in the Admin console on a live tenant at the review date.
Sources you can check
Related pages
Want your organizational unit tree simplified?
A discovery audit maps every unit against the settings it actually changes and returns a smaller tree you can apply without losing a single policy difference.