Google Workspace Organizational Units: Structure, Strategy, and Admin Management Guide

Organizational Units (OUs) are how Google Workspace admins apply different settings to different sets of users. Almost every feature you configure in the Admin Console (2-Step Verification enforcement, Gemini access, Drive sharing, Gmail routing, device policies) can be applied to the whole organization or scoped to specific OUs.

Getting your OU structure right is one of the most important foundational decisions in a Workspace deployment. This guide explains how OUs and inheritance work, how they interact with groups and configuration groups, proven structures, step-by-step management, common scenarios, and how to troubleshoot “why does this user have this setting?”

---

What Are Organizational Units?

OUs are containers in the Admin Console that hold users and devices (such as Chromebooks). Every user belongs to exactly one OU. You apply settings to an OU, and those settings apply to everyone in it, unless a child OU overrides them.

Key behaviors:

• OUs are hierarchical. Child OUs inherit settings from their parent by default.
• A child OU can override any inherited setting; clicking Inherit puts it back to the parent’s value.
• Each user is in one OU at a time. Moving a user changes which settings apply to them.
• The top-level OU is your organization itself. Settings there are the default for everyone.
• Settings changes can take up to 24 hours to reach every user, though most apply much faster.

---

OUs, Groups, and Configuration Groups

This is the most common point of confusion for new admins, because groups can do some of what OUs do.

Configuration groups let you apply settings to a group of users wherever they sit in the OU tree. For example, give a “Gemini pilot” group access to Gemini without moving those users out of their department OUs. A user’s group settings always override their OU settings; if they’re in several configuration groups, the highest-priority group wins. One exception: a 2SV policy set on a child OU takes precedence over a configuration group.

Configuration groups work for many services, including Calendar, Drive, Meet, Sites, Keep, Vault, Gmail user features, account recovery, Context-Aware Access, and data regions. Groups created in the Google Groups app can’t be used, and dynamic groups need the security label.

Rule of thumb: use OUs for the main policy structure that rarely changes, Google Groups for email and resource access, and configuration groups for exceptions and pilots.

---

Structuring Your OU Hierarchy

There’s no single right answer, but there are proven patterns.

Pattern 1: Department-based

Company Root
├── Finance
├── HR
├── IT
├── Legal
├── Marketing
├── Operations
└── Sales

Simple and intuitive. Works when departments need meaningfully different settings (Finance needs stricter sharing; IT needs developer tools).

Pattern 2: Employee type

Company Root
├── Employees
├── Contractors
├── Service Accounts
└── Shared / Kiosk

Useful when access differs mainly by employment type, for example, contractors shouldn’t have Gemini or external sharing.

Pattern 3: Mixed (most common)

Company Root
├── Employees
│   ├── Finance
│   ├── HR
│   ├── IT
│   └── Sales
├── Contractors
├── Service Accounts
└── Devices
    ├── Chromebooks - Staff
    └── Kiosks

Departments for policy differences, separate OUs for contractors and non-human accounts, and a device branch for Chromebooks and kiosks.

Pattern 4: Location-based (multi-country)

Company Root
├── Region - Americas
├── Region - EMEA
└── Region - APAC

Useful when data regions, language, or local compliance rules differ by country. Often combined with department OUs underneath.

How to choose

Ask one question for each proposed OU: “Will this OU have at least one setting that’s different from its parent?” If not, it probably doesn’t need to exist, a Google Group may do the job.

---

Creating and Managing OUs

Create an OU:

1. Admin Console → Directory → Organizational units
2. Hover over the parent OU and click Create organizational unit
3. Enter a name and optional description
4. Click Create

Move users to an OU:

1. Admin Console → Directory → Users
2. Select one or more users
3. At the top, click More, then Change organizational unit
4. Select the target OU, click Continue, review the message and click Change

Bulk move via CSV:

1. Admin Console → Directory → Users → Bulk update users
2. Download the template or your current user list
3. Set the Org Unit Path column (for example, /Employees/Finance)
4. Upload and review the preview before confirming

Rename or delete an OU: renaming is safe. Before deleting, move all users and devices out: an OU must be empty to be deleted.

---

Applying Settings Per OU

Every settings page in the Admin Console has an OU (and, where supported, group) selector on the left:

1. Open the settings page (for example, Apps → Google Workspace → Gmail)
2. Select the OU on the left
3. Change the setting
4. Click Override to keep the change for this OU regardless of the parent, or Inherit to return to the parent’s value

Example: turning off a feature for contractors

• Open the service’s settings page
• Select the Contractors OU
• Turn the feature off and click Override

Employees (and their child OUs) keep the feature; contractors don’t.

Turning a service on or off

Apps → Google Workspace → [service] → Service status controls whether an app is available at all. Turning Gmail off for a “Kiosk” OU, or Drive off for a “Service Accounts” OU, is done here.

---

Common OU Scenarios

Scenario 1: Stricter 2-Step Verification for finance and HR Finance and HR must use security keys; others can use any 2SV method. → Set Methods: Only security key on the Finance and HR OUs.

Scenario 2: Contractors with limited features Contractors shouldn’t use Gemini, share files externally, or install Marketplace apps. → On the Contractors OU, turn off Gemini, restrict external sharing in Drive, and limit Marketplace apps.

Scenario 3: Accounts used by systems Some integrations need a Workspace user account (for example, a scanner that emails documents). → Put these accounts in a Service Accounts OU, turn off apps they don’t need, and give them strong passwords and 2SV where the system supports it. For server-to-server integrations, use a Google Cloud service account with narrowly scoped domain-wide delegation instead of a user account.

Scenario 4: Kiosks and shared Chromebooks Shared devices in a warehouse or store need a locked-down setup. → Put the devices in a Kiosks OU and apply ChromeOS device policies (kiosk mode or managed guest sessions, guest mode off).

Scenario 5: Pilots You want 30 users across departments to trial a feature. → Use a configuration group rather than a new OU, so their departmental policies stay intact.

---

Troubleshooting: “Why Does This User Have This Setting?”

When a user sees a setting you didn’t expect:

1. Check their OU in Directory → Users
2. Walk up the tree: is the setting inherited from a parent, or overridden on their OU?
3. Check configuration groups: group settings override OU settings, and the “Overridden”/“Inherited” labels on a setting only reflect OUs, not groups
4. Check licenses: some settings only apply to users with a particular edition or add-on
5. Allow time: changes can take up to 24 hours to apply

Document which OUs override which settings; this check gets much faster.

---

Best Practices

Keep the hierarchy shallow. Two to three levels is ideal; five or more becomes hard to reason about.

Name OUs clearly. Finance beats FIN. Future admins should understand the structure without a legend.

Document your structure. Keep a simple diagram or sheet listing each OU, its purpose, and which settings it overrides.

Avoid one-user OUs. OUs are for sets of people. For individual exceptions, use configuration groups.

Plan OUs before syncing a directory. If you use GCDS or an IdP to provision users, decide the OU mapping before the first sync, so users land in the right place automatically.

Review after reorganizations. Mergers, reorgs, and new subsidiaries all need OU updates. Keep your Workspace structure in step with the business.

---

Conclusion

A well-designed OU structure is the foundation of effective Google Workspace administration. Use OUs for the stable policy backbone, configuration groups for exceptions and pilots, and Google Groups for email and access. Design it before you deploy, document every override, and revisit it when the organization changes.

---

Official Google documentation:

• Customize service settings using configuration groups
• How the organizational structure works

Related reading:

• Google Workspace User Lifecycle: Onboarding and Offboarding: OU assignment is the first step in user provisioning.
• Google Workspace Groups Administration Guide: groups handle email and access; configuration groups handle exceptions.
• Google Workspace Admin Security: 10-Point Hardening Guide: most security controls are applied per OU.