Organizational units vs groups in Google Workspace

By Patronum

August 10, 2026

Read Time: 5 mins

Organizational units vs groups in Google Workspace image

Use OUs for, use groups for
How organizational units work
How groups work for policy
Which one applies where
A worked example: contractors and Drive sharing
A second example: app access and Gmail settings
Common misconceptions
Frequently asked questions
Getting the OU right at account creation
Sources

An organizational unit is where a user lives in your Google Workspace hierarchy, and it sets their baseline policy. A group is a membership list used for email, sharing, and access, and it can override that baseline. Google’s rule is blunt: a user’s group settings always override their organizational unit’s settings.

Read that rule with its limit attached. Group settings override the OU only for services and settings Google supports as configuration groups or access groups. Everything else stays governed by the organizational unit.

Every user sits in exactly one OU, and in many groups. That asymmetry explains almost every policy surprise admins hit.

Use OUs for, use groups for

Use organizational units for: the stable shape of the organization (department, region, staff versus students), baseline policy for a whole population, and any setting Google doesn’t expose to configuration groups. Removing access is an OU job.

Use groups for: exceptions to that baseline, turning a service on for people scattered across several OUs, and the non-policy work groups already do (email, calendar invites, Drive sharing targets).

How organizational units work

OUs are a tree, and settings flow down it. Google’s Admin Help states that “A user or device belongs to only one organizational unit and inherits that organizational unit’s settings.” Change a setting higher up and every inheriting child OU changes too, but “Custom settings, however, remain unchanged.” An overridden child setting is pinned, so parent changes stop reaching it. Hence the classic “I changed it at the top, nothing happened” ticket.

The OU is chosen at account creation, so everything downstream inherits from it. Put a contractor in the default top-level OU and they silently get employee Drive sharing, Gmail routing, and app access. Fixing the OU later is easy. Undoing their sharing is not.

How groups work for policy

Groups do two policy jobs beyond email: Google’s configuration groups customize service settings, access groups customize service access. Beyond the override rule, two refinements matter.

In several configuration groups at once, “A user then gets the setting of the highest priority group they belong to.” Settings do not stack.
One documented exception: “A 2SV policy set on a child organizational unit always takes precedence over a configuration group setting.”

Google’s supported list includes Calendar, Drive, selected Gmail features, Google Meet, Vault and Google Cloud Platform, plus admin features like context-aware access and data regions. Check the current list rather than assuming: Google adds to it.

Which one applies where

	Organizational unit	Group
Per user	Exactly one	Many
Set at	Account creation	Anytime
Inheritance	Flows down the tree, custom settings stay pinned	No tree, priority order
Precedence	Loses to groups on supported settings only	Wins only where Google supports groups; 2SV on a child OU excepted
Good for	Baseline policy for a population	Exceptions, access, email, sharing
Coverage	Every Admin console setting	Only services Google lists
Also does	Nothing outside policy	Email, calendar invites, sharing targets

You bring in twelve contractors who must not share files outside the company. The OU way: create a /Contractors child OU, then switch external sharing off for it. Google’s documentation tells you to “select an organizational unit (often used for departments) or configuration group (advanced)” first. The group way: set the same thing on a contractors-restricted configuration group.

Both work. The difference shows in edge cases. If a contractor also sits in a higher-priority partners-external-ok group, that group wins and external sharing comes back. Google warns that either way, “It can take up to 24 hours to see changes.”

Our rule from cleaning up Workspace tenants: OUs for the stable shape of the organization, groups for exceptions. An OU per project builds a tree nobody can safely change.

A second example: app access and Gmail settings

Take an analytics team spread across five organizational units that needs a Google Workspace Marketplace add-on plus a SAML app. Five OU edits is the wrong shape. An access group is the right one: Google notes that “Users from different organizational units can belong to a group,” and that turning a service on for the group “Always overrides the organizational unit’s setting.”

The direction catches people out. Google is explicit: “Access groups can turn on user access to Google services. An access group can’t turn off user access to a service that’s turned on for an organizational unit.” An access group grants. It never revokes. To take a service away, you go back to the OU.

Gmail is the sharper caveat. Google’s supported list reads “Gmail (select features),” not all of Gmail, and Google warns that “Depending on your edition of Google Workspace, configuration groups might not be available for some services or settings.” Check the setting before designing policy around a group.

Google Admin console Drive and Docs sharing settings, showing the Users, Groups and Organizational Units selectors on the left

Common misconceptions

“A user can be in two OUs.” No. One OU, always. For overlapping policy, use groups.

“I’ll just fix the OU later.” You can move the user, but the sharing they did under the wrong policy doesn’t roll back.

Frequently asked questions

Can a Google Workspace user be in more than one organizational unit?

No. Google is explicit that a user or device belongs to only one organizational unit and inherits that unit’s settings. Use configuration groups when policy must come from more than one place.

Do group settings override organizational unit settings in Google Workspace?

Yes, but only for services and settings that support configuration groups or access groups. Google states that a user’s group settings always override their organizational unit’s settings, within that supported list. Anything outside it stays with the OU, and availability varies by edition. Two limits: a 2-Step Verification policy on a child OU wins, and an access group can only turn a service on, never off.

How many organizational units can I create in Google Workspace?

Google publishes no maximum count or nesting depth. Above 50,000 users it advises keeping “your organizational structure as simple and as flat as possible to improve the performance of account creation.”

How long do Admin console setting changes take to apply?

For Drive sharing settings, Google states it can take up to 24 hours, with old and new settings intermittently enforced. Plan around the lag; don’t test immediately.

Getting the OU right at account creation

The cheapest fix is putting the user in the right organizational unit on day one, with the right groups attached. That’s what Patronum’s onboarding automation does: provision the joiner with the correct license, OU, and groups as a policy, reassess on role change, strip access at exit. Patronum also handles Drive sharing governance at scale. For leavers, Patronum Archive retires the account cleanly, holding their mail and Google Vault data in a Google Cloud Storage bucket you own.