Organizational units and policy inheritance

Owen arrives at the fourth session with a draft he is proud of: an organizational unit tree that copies Birchline's organization chart exactly, with 61 units, one for every department, store and warehouse team. Sofia looks at it for a long time. "This is a picture of who reports to whom," she says. "An OU tree should be a picture of who needs different settings. Those are not the same thing." The rest of the session explains why, and by the end the tree has 14 units.

What an organizational unit is

An organizational unit (OU) is a container in the Google directory that holds users and devices (and, for some settings, other objects such as Chrome browsers). OUs form a tree: at the top is the top-level organization, which is named after the account and contains everything, and below it are child OUs, which can have children of their own. Every user belongs to exactly one OU at any time. New users go to the top-level organization unless placed elsewhere.

The purpose of OUs is to apply settings. Almost every setting in the Admin console, whether a service is on or off, how Drive sharing works, which Chrome extensions are allowed, can be set for the top-level organization and then changed for specific OUs below it. OUs are also used to scope admin roles, so a regional admin can manage only the users in their region (lesson 9), and to decide which users receive automatic licences (lesson 6).

Inheritance and overrides

Settings flow down the tree. A child OU inherits each setting from its parent unless an administrator overrides it at the child. If Drive external sharing is allowed at the top-level organization, it is allowed in every OU below, unless one of them overrides it. If the Stores OU turns external sharing off, every OU under Stores inherits off, unless one of those overrides it again.

The console shows this on every settings page. With an OU selected, each setting shows either Inherited (with the value from above) or Overridden (set at this OU). An overridden setting can be reverted to inherit, removing the local value so that the parent's value applies again. Sofia's tip is that inherited is the normal state and every override is an exception that should have a reason in the change log.

Inheritance has two practical consequences. First, a change at the top-level organization affects every OU that has not overridden that setting, which is usually most of the company; check before changing anything at the top. Second, moving a user from one OU to another changes their settings immediately, because their settings come from their new position in the tree. Moving someone to the wrong OU can switch services on or off for them without any other action.

Working out the effective setting

For any user and any setting, the effective value is found by starting at the user's OU and walking up the tree until a level that sets the value is found. Owen writes the rule as a small function so that he can test his tree design against real cases.

# Each OU path maps to the settings overridden at that level ('/' is the top-level organization).
overrides = {
    "/":                     {"external_sharing": "allowed", "chat": "on", "drive_desktop": "on"},
    "/Stores":               {"external_sharing": "off", "drive_desktop": "off"},
    "/Stores/Store managers": {"external_sharing": "allowed with warning"},
    "/Warehouses":           {"external_sharing": "off"},
    "/Contractors":          {"chat": "off"},
}

def effective(ou, setting):
    path = ou
    while True:
        if setting in overrides.get(path, {}):
            return overrides[path][setting], path
        if path == "/":
            return None, None
        path = path.rsplit("/", 1)[0] or "/"

for user, ou in [("store associate", "/Stores/Store 12"),
                 ("store manager", "/Stores/Store managers"),
                 ("finance analyst", "/Head office/Finance"),
                 ("contract designer", "/Contractors")]:
    for setting in ("external_sharing", "chat", "drive_desktop"):
        value, source = effective(ou, setting)
        print(f"{user:18} {setting:17} {value:22} (set at {source})")

store associate    external_sharing  off                    (set at /Stores)
store associate    chat              on                     (set at /)
store associate    drive_desktop     off                    (set at /Stores)
store manager      external_sharing  allowed with warning   (set at /Stores/Store managers)
store manager      chat              on                     (set at /)
store manager      drive_desktop     off                    (set at /Stores)
finance analyst    external_sharing  allowed                (set at /)
finance analyst    chat              on                     (set at /)
finance analyst    drive_desktop     on                     (set at /)
contract designer  external_sharing  allowed                (set at /)
contract designer  chat              off                    (set at /Contractors)
contract designer  drive_desktop     on                     (set at /)

The output answers questions that the organization chart cannot. The store associate in Store 12 has external sharing off because of the Stores OU, even though Store 12 itself sets nothing. The store manager has sharing allowed with a warning because their OU overrides Stores. The finance analyst inherits everything from the top. The contract designer has Chat off but inherits everything else. If any of these is not what the business wants, the tree or the overrides need to change.

Designing an OU tree: settings, not reporting lines

Google's recommended practice is to design OUs around groups of users who need different settings, keep the tree as flat as is practical, and use groups rather than OUs to express other relationships such as team membership or project access. An organization chart changes every month; settings needs change rarely. A tree built on settings needs is stable, and a stable tree means fewer moves, fewer surprises and simpler admin roles.

Sofia walks Owen through the questions that decide whether a unit earns its place: does this population need at least one setting that differs from its parent? Will a delegated admin need to manage exactly this population? Is automatic licensing different here? If the answer to all three is no, the population belongs in a group, not an OU.

Applying those questions removes most of Owen's 61 units. The 40 stores do not need different settings from one another; they need the same frontline settings, so one Stores OU holds all store staff, with a child for store managers, who need more sharing and Gemini features. The two warehouses share settings. Head office departments mostly share settings, but Finance needs stricter external sharing and longer retention, and IT needs access to beta features for testing. The pilot needs its own OU so that new settings can be tried there first.

Department and store still matter, of course, for email lists, Drive access and reports. Those live in groups (lesson 5) and in user attributes such as department and cost centre, where they can change freely without moving anyone in the tree.

Configuration groups: settings that cross the tree

Some settings apply to people scattered across OUs. Birchline's 25 Gemini early testers sit in Head office, Stores and Warehouses; the bilingual customer service staff who need a particular Chat app are in three OUs. Moving them into a special OU would break the settings they get from their real OU. The answer is a configuration group: many settings pages let you apply a setting to a group instead of an OU, using the Groups tab next to the OU tree.

A setting applied to a group takes precedence over the OU setting for the group's members. When a user is in several groups that set the same thing differently, the console lets the administrator order the groups to decide which wins. Not every setting supports groups, and the console shows which do. Sofia's rule: OUs for the broad, stable shape of the organization; configuration groups for exceptions that cut across it; and nobody in more than two configuration groups for the same setting.

Creating, moving and deleting OUs

OUs are created in Directory, Organizational units: choose the parent, give a name and an optional description. Users are moved by selecting them in the user list and choosing a new OU, or in bulk with a CSV update, or by synchronization, which can place users in OUs based on directory attributes (lesson 7). Devices and Chrome browsers can be moved similarly.

An OU can be renamed or moved under a different parent. Renaming changes the OU path, which matters for anything that refers to the path: CSV files, scripts and synchronization rules that place users by path. An OU can be deleted only when it is empty. Before reorganizing, Sofia exports the list of overrides at each OU so that she can check that nothing was lost.

Testing changes with the pilot OU

Birchline's change process uses the Pilot OU as a gate. A new setting is first applied to Pilot, tested by the 14 IT users for at least a week, and only then applied to the wider OU. Because Pilot is a child of the top level, the pilot users otherwise receive the normal company defaults, so tests are realistic. When the pilot ends, the members will move to their real OUs, and Pilot will be kept for future testing with a few volunteers from each area.

A last design check is to read the tree aloud as a list of settings decisions. For each unit, Owen says in one sentence what is different there: Finance has stricter sharing and longer retention, Store managers have more sharing and AI features, Departed staff have every service off. A unit he cannot describe in one sentence is either doing too much or should not exist.