Google Organisational Units: The Complete Admin Guide

Google Organisational Units: The Complete Admin Guide

Google Organisational Units: The Complete Admin Guide is the ultimate guide for super administrators on Google organisational units and how to manage data retention within them.

Wait! Before you start: While Google Organisational Units are good way to manage access across your teams, it might not be the most efficient way if you’re only looking to control access to files and documents. The best way to manage access for files and documents is using Google Drive and it’s permissions system as long as you use our Google Drive structure which we explain in our blog post here.

Best practices for Google organisational units

• Keep it simple: Create only the necessary organisational units, aiming for simplicity. Make a new unit if you need different service access or settings for users or devices. If everyone needs the same access, stick to one unit.
• Do not over-organise: Avoid excessive categorisation to ease policy assignment later. Only make units with a clear purpose. For instance, separate students and staff in a school, but avoid dividing students by grade unless needed.
• Pay attention while moving units: When rearranging, be mindful of existing local settings. Google Organisational Units: The Complete Admin Guide will show you how moving units keeps local settings, while inherited ones change based on the new parent unit. Knowing where settings are applied is crucial. Amplified IT’s support team can help generate a report of local settings for educational institutions using Google Workspace for Education.
  
• Choose the right restructuring method: Start fresh to discard current settings, or move units to keep them. Consider a mix—move and rename units with complex settings, and create new ones for full inheritance.

FAQ’s about Organisational Units

Q: Are organisational units related to domains?

A: No, they are unrelated. Organisational units determine a user’s available services and settings, while domains define their account username and email address.

You can have multiple domains within one Google Workspace account. By default, all users across domains are in the top-level organisational unit. To apply different policies to users in a domain, place them in their own unit.

An organisational unit can have users from different domains, and users in a domain can be in multiple units.

Q: Can settings be customised for a single user using an organisational unit?

A: Yes, to customise service access or settings for a single user, create a unit just for them and adjust settings accordingly. However, this is rare and not standard practice.

Q: How do I change my Google organisational unit?

A: An admin can move a user to another unit in the Admin console.

Q: Does organisational structure impact user addition rate in Google Workspace?

A: Yes, a simple, flat structure speeds up user creation, especially for large numbers (over 50K). You can create a deeper hierarchy later.

Q: How are organisational units different from access groups?

A: Organisational units determine user services and features, while access groups turn on services for specific users within or across units. To enable a service for specific users in a unit, create an access group, move users to it, and activate the service.

An overview of organisational units within the Google Admin console

Organisational units are like containers within your Google Workspace’s admin console that allows super administrators to group different users together. This could be based on factors like department, location, or job function. Administrators can apply specific settings (like which apps are available) to each organisational unit to tailor the experience for different groups of users.

Why use organisational units

In Google Workspace, everyone starts with the same apps and settings. However, most organisations have different teams with specific needs. Administrators can use organisational units to customise app access and settings for these various groups.

Specific job functions often require specialised tools. For instance, your sales team will likely need a CRM service, while your finance team requires specialised accounting software – tools other departments might not need at all. Additionally, as data protection laws get stricter, organisational units help ensure that only the right people have access to sensitive information. Overall, Google Workspace organisational units give you the control to make sure everyone in your organisation has access to the specific tools and data they need to do their jobs effectively.

Using organisational units, administrators can:

• Control which Google services (Gmail, Calendar, Drive, etc.) specific groups can use.
• Tailor how services work for different teams (e.g., setting storage limits, restricting file sharing outside the organisation).
• Configure settings for Chrome OS devices if you have added those devices to an Organisational Unit.
• Apply security policies to protect sensitive data based on user groups.

Overview of an organisational structure

In a Google Workspace account, all users and devices are initially placed in a main organisational unit, typically named after the domain. The settings applied in the Admin Console affect this main unit and consequently, all users and devices in the account. For customisation, organisations can create separate units for specific teams like Sales, Marketing, and HR, allowing tailored access to Google Workspace apps and settings.

You can create as many organisational units as you want below the top-level unit, but a user can only be a part of one organisational unit at a time. Child organisational units can be created under each organisational unit.

By default, a child organisational unit inherits the settings of the parent, and any changes made to the parent organisational unit will also reflect in the child organisational units. But administrators can create custom settings specific to each child organisational unit to override the settings inherited from the parent organisational unit.

In the diagram above, the main organisational unit has several smaller ones beneath it, such as Marketing, HR, Sales, IT, Finance, and Test. Some of these smaller units have even more units under them, all inheriting settings from their parent or with custom settings applied.

For instance, YouTube is enabled for users in the “Marketing” unit, so all users in its child unit “Social Media Management” can access YouTube by default.

Meanwhile, a custom setting enables Google Drive access for users in the “Recruitment” unit, overriding inherited settings from the parent. Therefore, regardless of the settings in the “HR” unit, users in its child unit “Recruitment” have access to Google Drive.

Building an Organisational Structure

After creating a Google Workspace account, admins can make as many organisational units as needed. To manage the organisational structure, one must have the Organisational Units privilege assigned to them in the Google Admin console. A Super administrator automatically possesses all admin privileges.

Making a new organisational unit

To apply different settings to a group of users or Chrome devices, admins can create a new organisational unit below the main one, put the users or devices in it, and apply specific settings to that unit.

To make a new organisational unit, follow these steps:

Step 1: Open the Google Admin Console and go to the Organisational Units section.

Step 2: Click the ‘+’ icon at the top left corner of the page.

Step 3: Provide a name and description for the new unit. Select the parent unit where you want to place it. By default, it will be under the main unit.

Step 4: Click Create.

Pipeline pro tip: You can also create a new unit directly under an existing one by clicking the ‘+’ icon next to it.

Allocating users to an organisational unit

Once you’ve created an organisational unit, you must allocate users to it to configure service access and settings for a particular group. By default, all users in a Google Workspace account are in the main organisational unit; admins can relocate users to other child units if necessary.

To move users to an organisational unit, follow these steps:

Step 1: Go to the Users tab on the Google Admin Console home page.

Step 2: In the All Organisations section on the left side, select whether you want to see users from all units or only selected ones. Then, pick the needed organisational unit from the list.

Step 3: Select the user(s) you want to move. Click More, then Change the organisational unit.

Step 4: Choose the new unit for the user. Review the settings and click Change.

For instance, in the ‘Sales’ unit, there are two sub-units: ‘USA’ and ‘Europe.’ If a user is placed in the ‘Europe’ unit, they won’t be part of the ‘Sales’ unit anymore, even though it’s the parent. However, both ‘USA’ and ‘Europe’ users will inherit ‘Sales’ settings, unless customised settings are applied.

Note: When you add Chrome devices to the Google Admin Console, they start in the top-level unit. Move them to different units to set rules. For more information on adding Chrome Devices to the Google Admin Console, click here.

Editing permissions for an organisational unit

After placing users and devices into organisational units, you can establish user policies. By default, child units inherit settings from their parents, but custom settings can overwrite these. Administrators can allow certain individuals in the organisation to use a feature or service in their managed Google account while restricting others.

Once users with specific needs are grouped into organisational units, the desired settings can be applied to those units. Using organisational units, an administrator can:

1) Turn services on or off for different users
2) Change service settings for different users

Turn app services on or off for users

A Google Workspace administrator can manage users’ access to various Google services. Users can only access services that are enabled for them in the Google Admin console when they sign into their accounts.

Here’s how you can switch on or switch off an app service for specific users:

Step 1: On the Google Admin Console home page, go to the Apps section.

Step 2: Click on the Google Workspace tab.

Step 3: On the left, choose the organisational unit containing the users you’re managing. This displays app statuses for that unit.

Step 4: Check the box next to the service to enable or disable it. At the top, select whether to keep the service On or OFF for the selected unit. For child units, you can select Inherit to adopt the parent unit’s settings for the service.

The simplest method to control service access for certain users is through organisational units. You add users to an organisational unit and then enable the service for that unit only. However, if you already use organisational units for other settings, you might prefer using access groups to manage service access for specific users.

Sometimes, a service needs to be enabled for users across different organisational units. Access groups allow administrators to enable a service for specific users regardless of their organisational structure, more on that below.

Changing service settings for users

Just as users’ access to Google services can be managed with organisational units, administrators can also personalise service settings. To customise service settings for particular users, follow these steps:

Step 1: Sign in to the Google Admin Console. Navigate to Apps -> Google Workspace.

Step 2: Choose the app you want to customise from the list. This opens the app settings page.

Step 3: Click on a setting panel to expand it. Then, select the organisational unit containing the users you want to adjust the settings for.

Step 4: Adjust the settings and choose “Override” (or click “Save” if it’s the main organisational unit).

App Access Control

As of March 2024, Google Workspace Admins can now configure several App Access Control (AAC) policies at the Organisational Unit (OU) level. Previously, this was only possible at the domain level. Specifically, this applies to:

• What happens when users try to sign in to unconfigured third-party apps with their Google Account.
• Whether internal apps built by your organisation can access restricted Google Workspace APIs.
• Whether custom messages will be shown to users when they can’t access a blocked app.

Organisational units vs. access groups

In larger organisations, it’s wise to enable services for groups of users instead of entire units. This allows for more precise control over service access without altering the organisational layout. In cases where certain users from various units need access to a particular service, administrators can’t assign users to multiple units. Instead, they can create access groups to manage service access for users across units.

Pipeline Digital Protip: Access groups can only be made using the Google Admin Console, Google Cloud Directory Sync, or Directory API. Groups created with Google Groups or dynamic groups cannot be used as access groups.

In the Google Admin console, an admin can disable access to a Google service like Google Drive for an organisational unit. If some users in that unit still need Drive, there are two options:

Option 1: Transfer the users to another unit where Google Drive is enabled. (This will change the unit’s structure by removing the users.)

Option 2: Form a group for these users and activate Google Drive for the group. All members can access the service, even if their unit doesn’t have access. These groups, known as access groups, can contain any users or groups in your organisation.

Customising service access using access groups

To grasp how access groups function, imagine an organisation where Google Drive is disabled for the Sales organisational unit (OU). Due to inheritance, users in the US and UK child OUs won’t have access to Google Drive by default. However, the Sales heads in both the US and UK units require access to Google Drive.

In this scenario, the administrator can create an access group in the Google Admin console, add the Sales heads to this group, and enable Drive access for the group. By utilising access groups, service access can be tailored for users across organisational units without changing the organisational structure.

Note: Access groups enable user access to Google services but can’t disable access if it’s already enabled for their organisational unit. For instance, if Google Meet is off for an organisational unit, you can turn it on for specific users within that unit by adding them to an access group with Meet enabled. However, if Meet is already on for the unit, you can’t turn it off for specific users by adding them to an access group.

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

The below table gives the differences between an access group and an organisational unit:

Creating an access group

As mentioned earlier, only groups made through the Admin console, Directory API, or Google Cloud Directory Sync can be used as access groups. You can’t utilise 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.

Customise service settings using configuration groups

Just like access groups customise service access, configuration groups customise service settings (like Drive Sharing options) for a group of users in one or more organisational units. These groups are called configuration groups.

To learn more, read Customise service settings with configuration groups

Role as admin in an organisational unit

In the Google Admin console, a Super Administrator can delegate management of the organisational account by giving users administrator roles. This grants them access to the Admin console. Admins can assign users pre-built roles for standard tasks or create custom roles. Find out more about administrator roles in the Google Admin console.

When giving a user a role, an administrator can limit it to a specific organisational unit. For instance, a user can be given the User Management Admin role for the ‘Sales’ unit. This allows them to manage user accounts only within the ‘Sales’ unit, not in other units like ‘HR’ or ‘Marketing’.

Administrator permissions needed

A custom role can have one or more admin permissions for particular tasks in your Google Admin console. The permissions chosen when assigning the role to a user decide which controls appear on their Admin console and what settings they can handle.

For an organisational unit, a custom role can only have specific permissions. If additional permissions are given, the role won’t be limited to the organisational unit.

Create a custom administrator role for an organisational unit

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

Step 2: Provide a name and description, then click Continue. Choose the permissions you want to assign to the user from the list and click Continue. Only select permissions relevant to organisational units. (See Administrator Permissions Needed above)

Step 3: Review the selected permissions and click Create Role to make the custom administrator role. Click Assign users.

Step 4: Enter the user you’re assigning the role to. Select the organisational unit you want to restrict the role to.

Step 5: Click assign role. The assigned admin can now manage specific tasks for users in the chosen organisational unit.

Managing data retention in Google organisational units

Administrators can retain data for users in an organisational unit using two methods:

• Retention rules
• Holds

To use retention rules or holds, you need access to Google Vault. Find out how to get Google Vault for your organisation.

Keep data for an organisational unit using retention rules.

To keep data for users in an organisational unit, make a custom retention rule in Google Vault. Here’s how:

Step 1: Log in to Google Vault. Go to Retention -> Custom Rules -> Create.

Step 2: Pick the service for the rule and click Continue. You’ll need a separate rule for each service.

Step 3: Select the organisational unit to retain data for and click Continue.

Step 4: (optional) Set conditions for data coverage or skip for all data. (Applies to Gmail or Groups.)

Step 5: Choose how long to keep the data:

• Keep messages forever or
• Set a specific retention period.

Step 6: If you choose a retention period, decide what to do when it ends. Then, click Create.

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

Retain data using holds

To retain data for users in an organisational unit using holds, do the following:

Step 1: Log in to Google Vault and choose Matters.

Step 2: If the matter isn’t created yet, click Create, then enter the matter name and description. Otherwise, open the existing matter.

Step 3: Open the matter and go to Holds -> Create.

Step 4: Name the hold, pick the service for data retention, and click Continue.

Step 5: Select the organisational unit for data retention and click Continue. (You may need to select additional options based on the service chosen.)

Step 6: (optional) Set hold conditions, then click Create. (Only applicable for Gmail or Groups; for other services, you can create the hold directly in Step 4.)

Limitations of using retention rules and holds for backups

While retention rules and holds in Google Vault can keep data at an organisational unit level, they aren’t meant for backup and restore purposes. Thus, they come with significant limitations as a backup solution. You can see all the limitations of using Google Vault as a backup solution by clicking here.

And there you have it! Your Google Organisational Units: The Complete Admin Guide should give you a deep dive into your questions about setting up Google Organisational Units for business.

Did you find Google Organisational Units: The Complete Admin Guide helpful?

Feel free to sign up for our other great Google Workspace updates and keep up to date with our other Google Workspace blogs.