As Microsoft Purview continues to grow, Admin Units have quietly become one of the most important features for organisations trying to delegate compliance and governance responsibilities in a structured way. They bring real value, especially in global environments where you need boundaries between regional teams, departments, or subsidiaries.
At the same time, Admin Unit support is not uniform across Purview workloads. Documentation can be ahead of or behind what is visible in the product. And some behaviours only become clear when you test them directly.
This article is a practical summary of what Admin Units currently support in Purview, what the documentation says, and what I observed through hands-on testing. If you’re planning to use Admin Units in your governance operating model, these nuances matter.
Administrative units or Admin Units (AUs) in Microsoft Entra ID let you scope administrative permissions to a defined set of users. Once an AU is applied to a role assignment, that administrator becomes a restricted admin, meaning they should only see and manage the users inside that boundary.
Purview historically took an “all-or-nothing” approach. A DLP admin could see everything. A Records Manager could modify every retention policy. An eDiscovery manager could search the entire tenant.
Admin Units aim to fix:
Too much visibility for tenant-wide compliance admins
The inability to delegate responsibilities to regions or departments
Privacy issues (HR shouldn’t see Finance logs, etc.)
Operational overload on central compliance teams
When AU support is implemented well, it significantly improves the governance operating model.
How Admin Units Work
You first create an admin unit in Microsoft Entra admin center and add members (could be static or dynamic, more information below) to the admin unit. Members can be users, groups or devices.
You then assign Admin Units to role group members in Purview like Information Protection Admins or Records Management role group, and those admins become restricted admins.
A restricted admin should:
Only see users in their AU
Only manage policies scoped to their AU
Only see alerts related to their AU
Only access Purview experiences within the AU boundary
Admin Units can be static or dynamic. You need to manually add members for static admin units. Dynamic admin units can be created by providing Entra rules like department -eq “finance” or country -eq “Germany”.
Finally, when you create policies in Purview like DLP policies, Sensitivity Label Policies etc., you an select this admin unit.
Using Dynamic Admin Units as a Workaround for Missing Adaptive Scopes in Purview DLP
One interesting advantage of Dynamic Administrative Units is that they can function as a practical workaround in workloads that do not yet support Adaptive Scopes like DLP policies.
Adaptive Scopes (available in retention and communication compliance policies) let you target policies based on attributes such as department, geography, or even user metadata that changes over time. They remove the need to manually update policy targets whenever people move teams, change roles, or join/leave the organisation.
But today, DLP does not support Adaptive Scopes.
This is where Dynamic Admin Units step in.
Because dynamic AUs allow you to build membership rules based on user attributes such as:
they effectively give you adaptive-like grouping for DLP.
This means:
As users move departments, regions, or legal entities, your DLP scoping automatically adjusts itself without touching the policy.
It isn’t a complete replacement for true Adaptive Scopes, but for DLP, it’s currently the closest mechanism available.
Observations, Gaps and Inconsistencies
Data Loss Prevention and Sensitivity Label Policies
Admin units work well with Data Loss Prevention Policies and Sensitivity label policies (both manual and auto-apply). A restricted admin can view and edit only those policies that are scoped to the admin unit they’re assigned to.
Retention: Where Behaviour Doesn’t Match Documentation
Based on hands-on testing, retention support for Admin Units behaves differently than the documentation suggests.
Key observations:
Restricted admins can view all retention and label policies
They can modify them
The product forces them to assign an AU before saving
A global policy can inadvertently become AU-scoped
This is important for operating models where retention governance is centralised. Teams should clearly label global vs AU-specific policies to avoid confusion.
Communication Compliance: Documented but Not Visible
Microsoft documentation says that admin units can be assigned for custom communication compliance polices but I didn’t find that in my testing. I was directly taken to the users and reviewers screen after the first screen. Maybe because it is in preview.
eDiscovery: Role Assignment Doesn’t Support Admin Units
Microsoft documentation says that you should be able to assign Admin Units to members in the eDiscovery role group, but I didn’t find that to be the case. The admin units option was missing.
Conclusion
Admin Units are a great step forward for governance in Purview, even if the support isn’t fully consistent yet. The key is knowing where they work well and where they don’t.
If you’re looking to make sense of Purview or want help building a clean, scalable governance model, I’m always happy to advise. This is what I do every day, and I’d be glad to support your team.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
