"Even part-time workers who just joined were permitted to share files externally and access any app, just like our executives. We realized how careless that was, but we were terrified that modifying settings would affect all employees, so we haven't touched anything." We recently heard this concern from an IT administrator at a company with about fifty employees. This is an extremely common challenge for organizations that have continued managing all employees under a single uniform configuration ever since introducing Google Workspace.
Early on, having identical configurations for all employees causes no issues. As headcount grows and employment types and departments diversify, however, applying identical rules to everyone suddenly becomes restrictive. Restricting permissions for new hires and contractors, elevating security for departments handling sensitive data like accounting and HR, testing new features in specific departments—these granular adjustments cannot be achieved under uniform company-wide management. In this article, we explain how organizational units (OUs) overcome this barrier, written from the perspective of ordering IT management.
Why a one-size-fits-all approach becomes restrictive
First, let us explore why uniform company-wide management hits a wall. Understanding this makes it clear what needs to be separated.
As a general rule, settings in Google Workspace have an "application scope." If all employees are grouped together, that scope is always "everyone." Therefore, if you want to stop using a particular app, you have no choice but to disable it for everyone, and if you restrict external sharing, it is restricted for everyone. You cannot apply settings to specific subsets, such as "only new hires" or "only the accounting department."
Here is how this plays out in real-world operations: you want to prevent employees on probation from using certain features, yet they remain available to everyone. You want to disable external email forwarding exclusively for departments handling confidential information, but disabling it company-wide disrupts operations in other departments. You want to test a new feature in a specific department, but turning it on deploys it across the entire company at once. You are left with only two choices: all or nothing—this is the fundamental limitation of a company-wide blanket approach. As your workforce and organization grow, this constraint becomes increasingly restrictive.
Organizational units (OUs) are "containers for separating settings"
Organizational units (OUs) resolve this constraint. While the term sounds formal, it is easiest to understand them simply as containers for applying different settings to different groups.
Within the Admin Console, you create containers (OUs) corresponding to departments or roles, and then assign employees to them. Once that is done, you can customize settings container by container, such as "can or cannot use this app," "external sharing allowed or not allowed," or "level of email security." For instance, you can create a "New Hires" container to restrict permissions, or an "Accounting Department" container to step up security. The idea is to transition from operating the entire company in a single container to breaking things down into the necessary units.
A key point to understand here is that containers have a parent-child hierarchy, and child containers inherit the settings of their parent. Department containers sit under the overarching company container; they inherit the company-wide baseline settings while allowing you to override only what is necessary. Consequently, there is no need to configure everything from scratch. You keep the company-wide foundation intact and apply differential settings only to the departments you want to change. Thanks to this mechanism of inheritance and overrides, departmental adjustments can be managed with practical levels of effort. This concept shares the same framework of a "company-wide foundation plus departmental security adjustments" discussed in our article on adjusting inbound Gmail security by department.
Where to divide containers: common approaches
So, what criteria should you use to divide containers? Splitting them into excessively granular units complicates administration, so the standard practice is to start with divisions that make a practical difference.
The first criterion is employment type and enrollment status. You vary permissions and accessible apps across categories such as regular employees, contractors/part-time staff, and employees on probation. Restricting permissions for external personnel and recent hires is an especially effective approach for preventing data leaks. The second criterion is departments handling confidential information. For departments dealing with compensation, personal data, or contracts—such as accounting, HR, and legal—you raise the security level by restricting external sharing and email forwarding. The third criterion is office locations and group companies. When multiple locations or affiliated companies share the same environment, you can separate administrators and tailor settings by location.
| Division criteria | Primary objective |
|---|---|
| Employment type / probation | Restrict permissions for external and new members |
| Departments handling confidential information (accounting, HR, etc.) | Restrict external sharing/forwarding and strengthen security |
| Office locations / group companies | Location-specific settings and shared administrative duties |
Another advantage of separating containers is that administrative tasks themselves can be delegated to departments. Because you can assign administrators who only have privileges over specific containers, you can delegate tasks—such as letting a branch manager handle password resets solely for members at that location. This prevents the company-wide administrator from having to shoulder everything alone. However, making containers too granular obscures the overall picture of your configuration, so the safe approach is to start by dividing into two or three broad containers and expand as needed.
Case study: a company that restricted new hire permissions and reinforced security only for accounting
Here is a concrete example. A company of about 50 employees (name withheld), in a situation similar to the opening scenario, came to us with a concern: "All employees share the same settings, meaning new hires and contractors have full access to everything. We want to tighten defenses specifically for accounting, but we are hesitant to modify settings company-wide."
Rather than immediately setting up a granular structure, we began with three containers: "Company-wide (Foundation)," "New Hires / Probation," and "Accounting." In the company-wide container, existing standard settings were kept as the baseline. In the "New Hires / Probation" container, external file sharing was temporarily restricted, and accessible apps were limited strictly to those required for their duties. In the "Accounting" container, external email forwarding was disabled, and inbound email security was heightened. Because the company-wide baseline was left untouched, daily work for other employees was completely uninterrupted. Additionally, procedures were established for moving accounts to the appropriate container upon retirement or transfer (a transition concept directly aligned with our article on transferring departing employee accounts). What worked was not a massive overhaul, but rather "isolating only the departments that needed changes right away from the company-wide foundation."
Start by identifying one setting that should not be the same for everyone
Designing organizational units does not require immediately classifying the entire company in fine detail. The first step you should take is to identify a single setting where a company-wide blanket rule is problematic. It could be external sharing for new hires, external forwarding for accounting, or a feature you want to test in only one department—any one of these is fine. That single point will define the first container you carve out from your company-wide foundation.
Start broadly with two or three containers, keep the company-wide settings as the foundation, and apply overrides only to the departments you wish to alter. Once operational routines are running smoothly, add more containers as needed. Starting small in this way helps you avoid both the rigidity of blanket rules and the administrative overhead of excessive segmentation. Take a moment to review how your company divides settings alongside the basics of the Admin Console.
Whether you want to restrict permissions for new hires and contractors, enhance security exclusively for accounting or HR, or separate administrative controls by branch without risking disruptions across the entire company, please feel free to reach out through GleamHub's free IT and Google Workspace consultation. From auditing current configurations and designing practical organizational units to applying departmental permissions, tuning security, and delegating administration, we work alongside you to implement solutions without halting company-wide operations.
Sources
- How the organizational structure works - Google Workspace Admin Help
- Add an organizational unit - Google Workspace Admin Help
- Turn a service on or off for Google Workspace users | Google Workspace Help
- Google Workspace Multi-Location Operations Guide: 4 Design Points for Organizational Units and Permission Management - XIMIX
