Why roles come before any fixing
In the Admin console you usually have a lot less power than you'd guess. One second-line tech can wipe phones for the London office and can't touch Paris. Another can reset passwords and can't see any devices. Both are working as designed. A Google Workspace admin account is the sum of the roles it holds. Each role is a bundle of privileges, and many privileges can be limited to one organisational unit (OU).
Think of a building pass. The Super Admin pass opens every door, including the server room and the room where passes get printed. Your pass should open only the doors your job needs. Least privilege is about more than security. If you can only reach the London OU, you can't wipe a Paris phone by mistake.
This course is independent of Google. Role and privilege names below were checked against Google's admin help in November 2026. Google renames and moves things, so check again before you rely on a name.
Step 1: Read what an account actually holds (read-only)
This is the path to the roles page. Opening it changes nothing as long as you don't click Assign or Unassign.
Admin console
└─ Menu > Directory > Users
└─ click the user's name # opens their account page
└─ Admin roles and privileges # scroll down to find it
├─ Roles -> "Assigned status" column: which roles are on
└─ Privileges -> every privilege, the role it came from,
and the OUs it applies to
What a sample reading looks like:
Roles
Help Desk Admin Assigned (via group it-firstline@) # indirect!
Device Support - London Assigned (direct)
Privileges
Users > Reset password OU: /Staff/London
Mobile Device Management >
Manage Devices and Settings OU: /Staff/London
Three gotchas from real support work:
- Google's help page says you need to be a super administrator to view this page. If you aren't one, ask your Super Admin to open it with you on a call, or to send a screenshot. That's normal, and it isn't a request for more rights.
- Roles can come from a group. This page shows roles assigned directly and roles inherited through group membership. The other view, Account > Admin roles > [role] > Admins, lists direct assignments only. So "I'm not in the list" doesn't prove you lack the role.
- Always read the OU column. Two people with the same role name can reach completely different parts of the estate.
Step 2: Prebuilt Mobile Admin or a custom OU-scoped role?
These are the prebuilt roles that matter for device support:
| Role | What it's for | Limit to an OU? |
|---|---|---|
| Help Desk Admin | Reset passwords for non-admins, view profiles | Yes |
| User Management Admin | All actions on non-admin users | Yes |
| Mobile Admin | Provision and approve devices, manage apps, block or wipe devices and accounts, set device policies | Documented as estate-wide. Only in organisations that signed up after February 2018 |
| Services Admin | Service settings, including device management | Much broader than a device job needs |
| Super Admin | Everything | No |
Mobile Admin is the quick option. Its drawback is reach: it covers every device in the tenant. When the job is "handle phones for one office", Google documents a narrower route, which is a custom role that contains only Services > Mobile Device Management > Manage Devices and Settings, assigned with an OU next to your name.
# How a custom role gets scoped (a Super Admin does this; you just recognise it)
Account > Admin roles > Create new role
Privileges: Services > Mobile Device Management
[x] Manage Devices and Settings # nothing else
Assign members > add user > click the OU next to them > /Staff/London
The trap: only certain privileges can sit in an OU-scoped role. They are Organizational Units, Users, Mobile Device Management (marked beta on Google's page), Chrome Management, User Security Management, and a few others. Add any other privilege and the role can no longer be limited to an OU.
An OU-scoped device admin can review devices, approve, block, delete and wipe them, and apply mobile settings, all within that OU. They can't do the jobs Google keeps at the top level: device reports and log events, automation rules, managing web and mobile apps, Apple VPP, and the Apple push certificate. Turning on iOS advanced management needs a Super Admin.
ChromeOS works the same way, with finer privileges under Services > Chrome Management. Examples are Manage ChromeOS Devices (read only), Manage ChromeOS Devices, Manage User Settings, Managed Browsers and Start Remote Desktop. All of them can be scoped by OU. A first-line tech who only looks up device status needs the read-only one.
Step 3: Spot Super Admin work and route it
Worked example. Priya is second line, with a custom role scoped to /Staff/London. Three tickets come in:
T1 London user lost iPhone, wipe the work account -> Priya: in scope, do it
T2 Paris user's Android shows "pending approval" -> not her OU: route to the
Paris admin
T3 "Apple push certificate expires in 5 days" -> top-level / Super Admin:
route with the banner
screenshot and expiry date
Creating or editing roles, assigning admins, top-level settings and Apple certificates all belong to the Super Admin. Google recommends that every tenant has at least one Super Admin and preferably two. When one of these tickets lands with you, send the task to the Super Admin. Don't ask for their rights. Write the request so they can act in one go: what's needed, for which user or OU, and why it's beyond your role.
Best practice: if your role turns out to be wider than your job (for example, you hold Services Admin only to approve phones), say so. A narrower role protects you as well.
Key takeaways
- Your power is roles × privileges × OU scope. Read all three on Directory > Users > [user] > Admin roles and privileges.
- Roles can come from a group. The per-role Admins list shows direct assignments only.
- The prebuilt Mobile Admin role covers the whole device estate. A custom role with only Manage Devices and Settings, assigned to one OU, is the smallest fit for "phones for one office".
- Adding a privilege that isn't on the allowed list removes the role's OU scoping.
- OU-scoped device admins can wipe, block and approve. Reports, rules, apps and Apple certificates are top-level jobs.
- Route Super Admin work to the Super Admin with the evidence attached. Don't ask for wider rights.