In this article

Organizational structure overview
Building the organizational structure
Organizational units and permissions
Organizational units vs. access groups
Admin role for an OU
Data retention management
Best practices
FAQs

A Complete Guide to Google Organizational Units

16 Dec 2024

6 min read

Anju George

Blog Articles

Article at a glance

Google organizational units (OUs) in Google Workspace enable tailored management of user settings, access, and data retention:

OUs allow for customized access to apps, services, and device management based on specific roles and departments.

Data retention policies can be applied at the OU level using Google Vault, ensuring compliance and security.

Access groups offer flexibility in managing service access without altering the OU structure.

What is the solution?

Leverage OUs for efficient management and use SysCloud for automated backups, ensuring comprehensive data protection and easy recovery.

This article is a one-stop destination for everything a super administrator needs to know about Google organizational units, along with data retention management at an organizational unit level.

1. An introduction to organizational units in the Google Admin console

Google defines an organizational unit as a group (not to be confused with Google groups) that a super administrator can create in the Google Admin console to apply settings to a specific set of users. Administrators can set up different organizational units and add users based on their job roles and the apps they need access to.

1.1. Why organizational units?

In Google Workspace, by default, every person has access to the same set of apps, with the same configuration. When an administrator adds or enables an app, access to the app is enabled for everyone. But most organizations are comprised of many smaller units or teams that focus on specific tasks or projects. Administrators might therefore be required to apply different settings to a specific group of users. This can be done by using organizational units in the Google Admin console.
In most organizations, people with different roles need different levels of access. For example, the Sales team needs access to a CRM service, or the Finance team needs access to an accounting app, while another department might not need access to these services at all. As data protection laws become tighter, it is important that only specific personnel have access to sensitive data. Google Workspace organizational units ensure that everyone in the organization has access only to the data and apps they need to do their jobs.

Using organizational units, administrators can:

Turn Google services on and off for specific groups of users
Configure service settings differently for specific groups of users
Configure settings for Chrome OS devices if you have added those devices to an Organizational Unit

2. Organizational structure overview

By default, all the users and devices in a Google Workspace account belong to a single organizational unit, called the top-level (parent) organizational unit which usually has the same name as your domain. All the settings that are applied in the Admin Console apply to this top-level organizational unit, and thereby, to all the users and devices in the account.

For example, an organization can have different organizational units for Sales, Marketing, and HR teams to give each unit access to only relevant Google Workspace apps and settings.

You can create as many organizational units as you want below the top-level unit, but a user can only be a part of one organizational unit at a time. Child organizational units can be created under each organizational unit. By default, a child organizational unit inherits the settings of the parent, and any changes made to the parent organizational unit will also reflect in the child organizational units. But administrators can create custom settings specific to each child organizational unit to override the settings inherited from the parent organizational unit.

google organizational units - inheritance

As shown in the above diagram, the top-level organizational unit has many child organizational units like Marketing, HR, Sales, IT, Finance, and Test. Some of these child units have more organizational units under them, with each having the same settings inherited from the parent or customized settings. For example, YouTube has been turned on for the users in the “Marketing” organizational unit. Therefore, by default, all users in “Social media management” which is a child unit of “Marketing” will be able to access YouTube. At the same time, a custom setting has been directly applied to the “Recruitment” organizational unit to turn on Google Drive access for the users in that unit, which overrides the settings inherited from the parent unit. Therefore, irrespective of the settings applied to the “HR” unit, users in “Recruitment" – which is a child unit of “HR" – can access Google Drive.

Note: When you change any setting for the parent organizational units, the settings for child units will also change by default, unless custom settings have been applied.

3. Building the organizational structure

After setting up a Google Workspace account, administrators can create as many organizational units as required.

Note: To manage the organizational structure, one needs to have Organizational Units privilege assigned to them in the Google Admin console. A Super administrator, by default, has all the admin privileges assigned to them.

3.1. Create a new organizational unit

To apply different settings to a set of users or Chrome devices, administrators can create a new organizational unit below the top-level organizational unit, place the users or devices in it, and apply unique settings to that unit. To create a new organizational unit, follow the below steps:

Step 1: Go to the Google Admin Console and navigate to the Organizational Units section on the Admin Console home page.
Step 2: Click on Create organizational unit.

Step 3: Add a name and description for the organizational unit. Choose the parent organizational unit under which you want to place the new organizational unit. By default, a newly created organizational unit will be placed under the top-level organizational unit.

Note: The organizational unit's name may not be unique within the organization hierarchy but its name is unique amongst its sibling organizational units. Also, an organizational unit's name is case insensitive.

Step 4: Click Create.

Note: You can also directly create a new organizational unit under an existing organizational unit by using the ‘+’ icon next to it.

create google organizational unit under existing unit

Learn how to move, rename, or delete a Google organizational unit

3.2. Move users to an organizational unit

Once an organizational unit is created, users need to be added to it so that you can configure service access and settings to a specific group of users. By default, all users in a Google Workspace account belong to the top-level organizational unit; administrators can move users to other child organizational units if needed.

To move users to an organizational unit, follow the below steps:

Step 1: From the Google Admin Console home page, select the Users tab.
Step 2: Under the All organizations section on the left side of the page, choose whether you want to view Users from all organizational units or Users from selected organizational units, and select the required organizational unit from the list.
Step 3: Select the user(s) that you want to move to another organizational unit. Click More options-> Change organizational unit.

Step 4: Choose the organizational unit to which the user has to be moved. Review the settings and click on Change.

It might take 24 hours for these changes to reflect in your account.

Note that a user can be a part of only one organizational unit at a time. This means that a user added to a child organizational unit will no longer be a part of the parent organizational unit.

For example, consider an organizational unit named ‘Sales’ which has two child organizational units under it called ‘USA’ and ‘Europe.’ A user added to the ‘Europe’ organizational unit will not belong to the ‘Sales’ organizational unit anymore, even though it is the parent unit. Nevertheless, the users in ‘USA’ and ‘Europe’ will inherit the settings applied to the ‘Sales’ organizational unit, unless custom settings have been applied.

3.3. Add a Chrome device to an organizational unit

When you enroll Chrome devices in the Google Admin Console, they are automatically added to the top-level organizational unit. These can be moved to different organizational units to configure settings and policies for specific devices. For example, to let teachers use Incognito mode on their Chromebook but not students, create an organizational unit containing the teachers' Chromebooks. Then, in the Devices settings section, turn on Incognito mode for just that organizational unit.

To move a device to an organizational unit:

Step 1: Go to Devices in the Google Admin Console.

Add chrome device to a google organizational unit

Step 2: Navigate to Chrome OS Devices.
Step 3: From the left panel on the page, select the organizational unit the device is part of. (You can also search for a particular device using its serial number)
Step 4: Select the device you want to move and click the Move option at the top of the page.
Step 5: Choose the organizational unit that you want to move the device to and click Move.

4. Organizational units and permissions

After adding users and devices to organizational units, these can be used to set up user and device policies. As mentioned earlier, all child organizational units, by default, will inherit settings from their parents, but these can be overridden by applying custom settings. A Google Workspace administrator can let some people in the organization use a feature or service in their managed Google account, but not others. Similarly, an admin can tailor settings for specific Chrome devices. Users or devices that have specific requirements are grouped into organizational units, after which, the desired settings can be applied to these units. Using organizational units, an administrator can:

1) Turn services on or off for different users

2) Change service settings for different users

3) Change settings for different Chrome devices

4.1. Turn app services on or off for users

A Google Workspace administrator can control users’ access to different Google services. When users sign into their account, they will only have access to services that are turned on for them in the Google Admin console.

Follow the below steps to switch on or switch off an app service for specific users:

Step 1: In the Google Admin Console home page, go to the Apps section.
Step 2: Click on the tab Google Workspace.
Step 3: On the left side, you can see all the organizational units listed. Select the organizational unit that contains the users for which you want to set up app services. This will show the status of all the apps for the selected organizational unit.
Step 4: Check the box next to the service you want to turn on or off. On the top of the page, choose whether you want to keep the service On or OFF for the selected organizational unit. For child organizational units, you can also choose the Inherit option, to directly inherit the settings the corresponding parent unit has for the selected service.

For detailed steps on how this can be done for each Google service, see the table provided in the Google support page.

The easiest way to manage service access for specific users is using organizational units. The users for which you want to turn on a service are added to an organizational unit, and then the service is turned on for just that organizational unit. However, if you already use organizational units to control other settings, you might want to use access groups to control service access for specific users. There can also be situations when a service needs to be turned on for a group of users who belong to different organizational units. Access groups allow administrators to turn on services for a group of users within or across organizational units without altering the organizational structure.

To learn more about access groups, refer to this Google support documentation.

4.2. Change service settings for users

Similar to how users’ access to Google services can be controlled using organizational units, administrators can customize service settings as well. To customize service settings for specific users, follow the below steps:

Step 1: Log in to the Google Admin Console. Go to Apps -> Google Workspace.
Step 2: From the list of Google Workspace apps, click on the app whose settings you need to customize. You will be taken to the app settings page.
Step 3: Click on a setting panel to expand that setting. Select the organizational unit that has the users for which you want to change the settings.

Step 4: Configure the settings and choose one of the following options:
a. Override: Overrides the inherited setting with a new value. b. Inherit: Reverts to the parent's setting if a custom value was previously set. (Click Save if it is the top-level organizational unit).

4.3. Change settings for Chrome devices

An administrator can control settings that are applied when people use a managed Chrome OS device, such as a Chromebook. Device-level settings apply for anyone who uses the device, even if they sign in as a guest or with a personal Gmail account.

Note: You need to be a Chrome Enterprise Upgrade or Chrome Education Upgrade customer to perform this.

Step 1: From the Admin console Home page, go to Menu -> Devices -> Chrome -> Settings -> Device settings.
Step 2: Navigate to Settings -> Device.
Step 3: Select the organizational unit which contains all the devices for which you need to change the setting. To apply the setting to all devices, leave the top organizational unit selected. Apply the settings you want. To learn about each setting in detail, refer the Google support page.

Note: You can quickly find a setting using the Search or add a filter option at the top.

If a setting is inherited from a parent organizational unit, it shows “Inherited from Google Default” below that specific setting. If you have applied customized settings to override the inherited setting, you can see “Locally applied” below the setting name.

Step 4: Click Save. It might take up to 24 hours to apply for the settings to apply to everyone.

5. Google organizational units vs. access groups

For larger organizations, it is better to turn on services for a group of users rather than an entire organizational unit. This lets you control service access for specific users without changing your organizational structure.

There might be situations when a few users across different organizational units require access to a specific service. Since a user can only belong to a single organizational unit at a time, administrators can create access groups to manage service access for a group of users across organizational units.

google organizational units vs access groups

Note: Access groups can only be created from the Google Admin Console, Google Cloud Directory Sync, or Directory API. A group created with Google Groups, or a dynamic group cannot be used as access groups.

In the Google Admin console, an admin can turn off an organizational unit’s access to a Google service, such as Google Drive. If some users in that organizational unit need to use Drive, there are two options:

1) Move the users to another organizational unit that has Google Drive turned on. (This will remove the users from the existing organizational unit, thereby altering the organizational structure)

2) Create a group for these users and turn on Google Drive for the group. Each member in the group can access the service, even if their organizational unit has the service turned off. Groups used in this way, called access groups, can include any users or groups in your organization.

5.1. Customize service access using access groups

To understand how access groups work, consider an organization where Google Drive is turned off for the Sales OU, and by default inheritance, users in the US and UK child OUs will not be able to access Google Drive. At the same time, the Sales heads of both US and UK units need access to Google Drive. For this, the administrator can create an access group in the Google Admin console, add the Sales heads to this group, and turn on Drive access for the group. Thus, by using access groups, service access can be customized for users across organizational units, without altering the organizational structure.

Note:

Access groups can only be used to turn on user access to Google services. They cannot be used to turn off user access to a service that is turned on for their organizational unit. For example, if Google Meet is turned off for an organizational unit, it can be turned on for selected users in that unit if they are added to an access group that has Google Meet turned on, whereas if Google meet is turned on for an organizational unit, it cannot be turned off for selected users by adding them to an access group.

If the Google service is off for a user’s organizational unit but on for their access group, you can turn it off for the group by unsetting it at the group level.

The following table gives the differences between an access group and an organizational unit:

Table Source: Google Support page

5.2. How to create an access group

As mentioned before, only groups created using the Admin console, Directory API, or Google Cloud Directory Sync can be used as access groups. You cannot use a group created with Google Groups, at groups.google.com, or a dynamic group as an access group.

Learn how to create an access group from the Google Admin console. (See Option 1)

Learn how to set up an access group.

5.3. Customize service settings using configuration groups

Similar to how service access can be customized using access groups, service settings (for example, Drive Sharing options) can be customized for a group of users in one or more organizational units. Groups used in this way are called configuration groups.

To learn more, read Customize service settings with configuration groups

6. Admin role for an organizational unit

In the Google Admin console, a Super Administrator can share the responsibility of managing the organizational account by assigning administrator roles to users in the organization. This gives the users access to the Google Admin console. An admin can assign the user a pre-built role available in the console to perform common business functions, or they can create a custom role to be assigned to the user. Learn more about administrator roles in the Google Admin console

When assigning a role to a user, an administrator can restrict the role to an organizational unit, so that the assigned user can perform management functions for that organizational unit alone. For example, a user can be assigned the User Management Admin role for the ‘Sales’ organizational unit. The user will be able to create or delete user accounts in the ‘Sales’ organizational unit only; they won’t be able to create or delete user accounts for ‘HR’ or ‘Marketing’ units.

6.1. Administrator privileges required

A custom role can include one or more administrator privileges for specific management tasks in your Google Admin console. The privileges you select when assigning a custom role to a user determine which home page controls are in the user's Admin console and what settings the user can manage.

A custom role for an organizational unit can only be assigned certain privileges. If any other privileges are granted to the custom role, the scope of the role will not be restricted to an organizational unit. The following are the privileges that can be assigned to a custom role for an organizational unit:

Organizational Units
Users
Mobile Device Management (beta)
Chrome Management
User Security Management
Shared device settings

Learn more about each of these privileges

If you use Google Vault archiving and eDiscovery service, the custom role for an organizational unit can also be granted any of these privileges:

Manage Matters
Manage Holds
Manage Searches
Manage Exports

Learn more about each of these privileges

6.2. How to create a custom administrator role for an organizational unit

Step 1: In the Google Admin console Home page, go to Admin roles and click Create new role.

Step 2: Enter a name and description, and click Continue. From the list of privileges, select the privileges that you want to assign to the user, and click Continue. Make sure to check only those privileges that apply to organizational units. (See Administrator Privileges Required)

Create a custom administrator role for a google organizational unit

Step 3: Review the privileges and click CREATE ROLE to create the custom administrator role with selected privileges. Click Assign members.
Step 4: Enter the user to whom you want to assign the role. Choose the organizational unit to which you want to limit the role.

Step 5: Click ASSIGN ROLE. The assigned admin will now be able to manage specific management tasks for the users belonging to the selected organizational unit.

7. Data retention management for Google organizational units

google organizational units - data retention management flowchart

There are two native ways in which an administrator can retain data of users belonging to an organizational unit:

1) Using retention rules

2) Using holds

To retain data using retention rules or holds, one needs access to Google Vault. Learn how to get Google Vault for your organization.

To learn more about Google Vault, read this article.

7.1. Retain data at an organizational unit level using retention rules

To retain data of users belonging to an organizational unit, a custom retention rule has to be created in Google Vault.

Step 1: Sign in to Google Vault. Click Retention -> CUSTOM RULES -> Create.

Step 2: Under Service, select the service to which you want to apply the rule and click Continue. A separate retention rule needs to be created for each service for which you need to retain data.

Step 3: Under Scope, choose the organizational unit for which you need to retain data, and click Continue.

Step 4: (optional) Choose the conditions that must be met for data to be covered by this rule, and click Continue. This step can be skipped if you want to retain the entire data.
Step 5: Choose how long to keep the data:
1) To permanently retain messages covered by this rule, choose Indefinitely.
2) To retain data for a specific period, and remove it once the retention period expires, choose Retention period, and enter the number of days (from 1 to 36,500).
Step 6: If you selected Retention period in the previous step, specify the action to be taken when the retention period ends. Click Create.

A retention rule will be created to retain data of users in the selected organizational units.

Learn more about how retention works in Google Vault

To learn more on how retention rules work for each Google service, refer the following articles:

A Guide to Data Retention in Gmail

A Guide to Google Drive Data Retention Policy

A Guide to Google Sites Retention

A Guide to Google Meet Retention

7.2. Retain data at an organizational unit level using holds

To retain data of users belonging to an organizational unit using holds, follow the below steps:

Step 1: Sign in to Google Vault and select Matters.
Step 2: If the matter already exists, click it to open it. Otherwise, click on Create to create a new matter. Enter the matter name and description.

Step 3: Open the matter you created and navigate to HOLDS -> Create.

Step 4: Enter the hold name. Under Service, select the service for which you want to place data on hold, and click Continue.
Step 5: Under Scope, choose the organizational unit you need to retain data for, and click Continue. (You might have to perform an additional step here depending on the service you choose. For example, if you have selected Drive in step 4, you need to choose whether to include items in shared drives as well)

Step 6: (optional) Set the conditions for the hold to be applied, and click Create. This step can be skipped if you want to retain the entire data. (This step is applicable only if you have selected Gmail or Groups in step 4. For other Google services, you can directly create the hold in Step 4)

To learn more about holds in Google Vault, click here.

7.3. Limitations of using retention rules and holds as a backup solution

Even though retention rules and holds in Google Vault can be used to retain data at an organizational unit level, they are not designed for the purpose of backup and restore, and therefore, have serious limitations as a backup solution. Click here to view all the limitations associated with using Google Vault as a backup solution

Third-party cloud backup applications like SysCloud are better options to back up your Google Workspace data.

8. SysCloud backup for Google Workspace

SysCloud backup for Google Workspace provides administrators the option to set up and configure backup at an organizational unit level, with different retention settings for each Google organizational unit.

9. Google organizational units best practices

Keep it simple: Create organizational units (OUs) only when you need to customize service access or settings for specific users or devices. Avoid creating unnecessary OUs if users can share the same access and settings.

You should create as many organizational units as necessary but as few as possible.

Avoid over-organizing: It may be tempting to meticulously categorize users, but this gives you more work when it is time to assign new policies. Create OUs only when they serve a clear purpose.
For example, in a school, students and staff might belong to separate OUs due to their differing settings and restrictions. However, placing students in separate OUs for each grade level is unnecessary unless explicitly required.
Understand inheritance when moving OUs: Modifying your organizational structure requires careful planning. When you move an OU to a new parent, check for locally applied settings, as these will remain in effect in the new location. However, inherited settings will adjust to reflect the new parent OU’s policies.
Understanding where custom settings are applied and how inheritance hierarchies function is crucial for maintaining effective configurations.
Choose a restructuring method based on your needs: If maintaining existing settings isn’t required, start fresh by creating a new OU structure. If preserving current configurations is critical, move OUs with their locally applied settings and rename them as needed.
There might be situations where a hybrid solution works better - moving and renaming some organizational units (that have locally applied settings that are too tedious to be configured again) and then creating new organizational units for which you want the settings to be fully inherited.
Utilize access and configuration groups: For scenarios where specific users across different organizational units require unique service access or settings, consider using access groups or configuration groups. This approach allows for customization without altering the organizational structure.
See the section Organizational units vs. access groups
Regularly review and audit organizational units: Periodically assess your organizational structure to ensure it aligns with current operational needs and that settings are appropriately applied. Regular audits help maintain an efficient and effective organizational hierarchy.

10. Frequently asked questions on Google organizational units

1. Are organizational units related to domains?

No, organizational units and domains are unrelated. A user's organizational unit determines which services and settings are available to that user. A user's domain determines their account username and email address.

You can have multiple domains within a single Google Workspace enterprise account. By default, all user accounts across all the domains will be part of the top-level organizational unit. If you want to apply different policies to users in a particular domain, you can place those users in their own organizational unit.
An organizational unit can contain users from different domains. Also, users in a domain can be distributed across any number of organizational units.

2. Can settings be customized for a single user using an organizational unit?

Yes, it is possible to customize service access or settings for a single user by creating an organizational unit specifically for that user. However, this approach is not recommended as standard practice and should be used sparingly.

3. How do I change my Google organizational unit?

An administrator can move a user to another organizational unit in the Google Admin console. Click here to know how.

4. Does organizational structure impact the rate at which users are added to a Google Workspace account?

Yes, the organizational structure can affect the speed of adding users to a Google Workspace account. Keeping the structure simple and flat allows faster account creation, especially for organizations with over 50,000 users. A deeper hierarchy can be built later if needed.

5. How are organizational units different from access groups?

An organizational unit determines which services and features are available to a set of users, whereas an access group is used to turn on a service for specific users within an organizational unit, or across organizational units. To turn on a service for specific users within an organizational unit, you can create an access group, move the specific users to that access group, and turn on the required service for that group.

Click here to read the differences between organizational units and access groups.

In this article

Organizational structure overview
Building the organizational structure
Organizational units and permissions
Organizational units vs. access groups
Admin role for an OU
Data retention management
Best practices
FAQs