Knowledge Base Article
Organizational unit structure
An Organizational Unit (OU) is a container within your Google Admin console that allows you to group users, devices, and other assets. The primary purpose of an OU is to apply policies and settings to specific subsets of your organization.
- Policy Inheritance: OUs operate on a hierarchy. Policies you set at a parent OU are inherited by all child OUs below it. This is a fundamental concept for simplifying management. For example, you can set a default homepage for all devices at the top-level OU, and it will apply everywhere unless you override it in a specific child OU.
- Users vs. Devices: A key best practice is to understand that users and devices can be in different OUs. A user's policies follow them regardless of the device they sign into, while a device's policies remain with the device, no matter who signs in.
Best Practices for Structuring OUs
The goal is to create a structure that is as simple as possible but as complex as necessary. Avoid creating OUs for every small group or purpose, as this can lead to an administrative nightmare.
1. Start with a Simple, Hierarchical Design
Your OU structure should be logical and easy to navigate. Common approaches include:
- By Location: For organizations with multiple offices (e.g., North America > California > Los Angeles).
- By Department or Role: Useful for corporate environments (e.g., Finance, Marketing, Engineering).
- By Job Level: Role within the organisation (e.g. Executives > Managers > Individual Contributors (ICs) ).
2. Separate Users and Devices Only When Necessary
While you can put users and devices in the same OU, it's often more effective to separate them to apply different policies.
- User OUs: Structure user OUs based on the policies you need to apply to people. This is for things like app access, content filtering, and user-specific settings. For example, an "ICs" OU might have restricted app access, while a "Exec" OU has full access.
- Device OUs: Structure device OUs based on the policies you need to apply to the physical hardware. This is for settings like network configuration, sign-in restrictions, and public session behavior. For example, you might have a "Laptops" OU for devices that travel and a "Kiosk" OU for public-facing devices.
3. Leverage Policy Inheritance to Simplify Management
Set the most common, organization-wide policies at the top-level OU. Then, only create child OUs to apply exceptions to these inherited policies.
- Example: If 90% of your devices use the same Wi-Fi settings, configure those settings at the top-level device OU. For a specific set of lab devices that need a different Wi-Fi network, create a "Lab Devices" child OU and override the Wi-Fi policy there. This saves you from re-configuring the same settings repeatedly.
4. Use Groups for Cross-OU Policies
While OUs are great for hierarchical policy application, Google Groups provide flexibility for applying policies to a specific set of users who are not in the same OU.
- When to use Groups: Use groups for temporary projects, special access to applications, or when a few individuals across different OUs need the same policy applied. For example, you could create a "Pilot Program" group and assign an experimental app to its members without moving them from their primary OUs.
Key Takeaways
- Plan first: Before creating any OUs, map out your organizational needs and how they translate to policies.
- Simplicity is key: Use as few OUs as you can while still meeting your policy requirements.
- OUs for hierarchy, Groups for flexibility: Remember that OUs manage hierarchy and inheritance, while groups provide a way to apply policies to a dynamic set of users or devices.
For more detailed explanations of how OUs and Groups work within the Admin Console, check out these articles in our help center: