One Microsoft 365 Tenant, Several Businesses: Delegating Admin Safely

Group tenants are common. A parent company sets up Microsoft 365 once, and every subsidiary, site or country lives in it. That works until one of those businesses needs its own IT support: its own service desk resetting passwords, creating starters, building laptops. The choice appears to be handing over Global Administrator, which nobody should agree to, or making the local team raise a ticket for every change.

There is a third option. Microsoft 365 can delegate administration over a defined slice of the tenant, so a local team manages its own users, mailboxes and devices and cannot touch anyone else’s. I built this for a London hotel group inside a wider group tenant; the outline is on the case studies page. This post explains how the pieces fit, and where the model stops.

Split the tenant, or segregate inside it?

The first decision is whether delegation is the right tool at all. A separate tenant gives a hard boundary, and brings a tenant-to-tenant migration with it. Segregation keeps everyone in one tenant and limits who can administer what.

Segregation fits when:

• The businesses share a domain, a global address list, Teams and SharePoint, and want to keep doing so.
• The requirement is about who administers the unit, not about hiding one unit’s data from another.
• Group IT is content to keep ownership of tenant-wide security policy.

A separate tenant fits when there is a legal or regulatory need for a hard boundary, when the business is being sold, or when the two sides cannot agree on shared security settings. Delegated administration is an operational boundary, not a data boundary. If the requirement is that the two businesses must not see each other at all, this is the wrong design.

Three layers that have to line up

The common mistake is to create an Administrative Unit, assign a role and stop. An Administrative Unit scopes directory roles in Entra ID. Exchange Online and Intune each have their own permission model, and each has to be scoped separately to the same set of people and devices.

If the three do not describe the same population, you get an admin who can reset a user’s password but not manage their mailbox, or who can see every laptop in the group.

Layer 1: Entra ID Administrative Units

An Administrative Unit (AU) is a container in Entra ID for users, groups and devices. Its purpose is to be the scope for a role assignment: instead of making someone a User Administrator for the whole tenant, you make them a User Administrator for one AU.

Membership can be assigned, where someone adds objects by hand, or dynamic, where a rule adds them based on an attribute such as office location, department or country. For anything that changes regularly, use dynamic: an assigned AU is only as accurate as the last person who remembered to update it. At the time of writing, dynamic rules cover users and devices, and groups are added manually; check the current Microsoft documentation for what is supported.

The roles I typically scope to the unit are:

• User Administrator, to create and manage the unit’s users.
• Groups Administrator, to manage the groups that have been placed in the AU.
• Helpdesk Administrator, for the service desk, limited to password resets and similar tasks for non-admin users.

What an AU-scoped role cannot do matters as much:

• It cannot manage objects outside the AU, or change tenant-wide settings.
• Putting a group in an AU lets the scoped admin manage the group itself. It does not bring the group’s members into scope; users have to be members of the AU in their own right.
• It should not be relied on for Exchange Online or Intune, which have their own models.
• Not every Entra role can be assigned at AU scope. Check the list of supported roles before designing around one.

Layer 2: Exchange Online RBAC

Exchange Online has its own role-based access control. Left alone, a role group such as Recipient Management applies to every recipient in the organisation. To limit it, you create a custom management scope, which is a recipient filter (for example, all recipients whose office or a custom attribute equals the unit’s value), and then a custom role group whose role assignments use that scope as their write scope.

Members of that role group can then manage mailboxes, shared mailboxes and distribution groups that match the filter, and nothing else. Two practical points:

• The filter is evaluated against the recipient. Shared mailboxes, room mailboxes and distribution lists need the attribute set too, or the local team will not be able to manage its own shared mailbox.
• Exchange Online can also scope role assignments to an Administrative Unit directly. Check the current documentation and test in a pilot before choosing.

Layer 3: Intune RBAC and scope tags

Intune permissions have three parts. A role, built-in or custom, defines what an admin can do. The role assignment’s scope groups define which users and devices they can do it to. Scope tags define which objects (devices, configuration profiles, compliance policies, apps) they can see in the admin centre.

For a delegated unit I create a scope tag for the unit, apply it to the unit’s devices through a group, tag the policies and apps the local team should manage, and assign a custom role limited to the unit’s device and user groups with that scope tag. A local engineer then sees their own devices and policies, not the rest of the group’s estate, and cannot edit a baseline that applies to other countries.

Licences by group, not by hand

A local admin picking licences from the full tenant pool, one user at a time, will eventually assign the wrong plan or use a licence earmarked for another business.

Use group-based licensing instead: one group per licence bundle, owned by the unit, drawing on the licences purchased for it. Adding a user to the group assigns the licence; removing them frees it. The local team manages group membership, which their scoped roles already allow. Group-based licensing has its own licensing requirement, so check what your plan includes.

Automated provisioning with a SharePoint list and Power Automate

Once the scope exists, new starters are the obvious thing to automate:

1. A SharePoint list acts as the intake form: name, job title, department, manager, start date, the licence bundle required.
2. A Power Automate flow triggers on a new item, creates the user with the attributes that place them in the right unit, resolves the manager, and adds the user to the licence group.
3. The flow writes the result back to the list item, including any failure and the reason, so the service desk has one place to look.

Depending on the connectors used, the flow may need a premium Power Automate licence. I compared Power Automate with the alternatives in Power Automate vs Copilot Studio vs Claude API.

The flow runs as a dedicated service account, and the governance around that account is the part people skip:

• Least privilege. Give it the same scoped roles as the local admins, not a tenant-wide role. A flow that can only create users in one unit can only break one unit.
• Not a person’s account. If the flow runs as the engineer who built it, it stops when they leave.
• Owned. A named owner, and the credential in a managed vault.
• Covered by Conditional Access on purpose. Decide how policy treats the account, document any exception, and review its sign-in logs.
• Limited access to the flow and the list. Anyone who can edit the flow can act as the service account, and anyone who can add a list item can create a user.

The attribute everything hangs on

Dynamic AU membership, the Exchange management scope and the Intune groups all key off an attribute: office location, department, country or a custom attribute. It becomes the definition of the unit, and it has to be clean.

When it is not, the failure is quiet. A new starter created without the attribute never joins the AU, so the local admin cannot find or manage them, and the ticket goes to group IT as “the user doesn’t exist”. A typo in the value does the same.

So I do three things:

• Audit and fix the attribute across existing users, shared mailboxes and devices before any role is assigned.
• Set it in the provisioning flow, from a fixed choice in the list, never free text.
• Report regularly on objects that look like they belong to the unit but are missing the value.

Dynamic membership is also not instant, so a flow that creates a user and then acts on them as a member of the unit needs a wait or a retry.

Limits and gaps

This model has edges:

• Some things stay tenant-wide. Conditional Access policies, domains, mail flow rules, many Teams and SharePoint admin settings, and most security and compliance configuration remain with group IT. A local team can own a SharePoint site without being a SharePoint administrator.
• Role scoping does not cover every task. There will be a short list of jobs the local team still has to request. Write that list down.
• Visibility is not restricted. A scoped admin can still see other units’ users in the directory, as any user can by default. What is limited is what they can change.
• Behaviour changes. Microsoft adjusts which roles and features support scoping. Verify against current documentation for your tenant.

For those reasons I always test with a pilot scope: a small AU with a few test users, a test mailbox and a test device, and a test admin account holding only the scoped roles. Sign in as that admin and try to do things you should not be able to do.

Document it and hand it over

A model only its designer understands will be undone by the first person who cannot work out why something is denied and grants a broader role to fix it. The handover includes:

• A one-page description of the scope: the attribute, its value, and the three layers that depend on it.
• The role matrix: who holds what, at what scope, in Entra, Exchange and Intune.
• What the local team can do, what it must request from group IT, and how.
• The provisioning flow: what it does, the service account, and how to run the process by hand if it is down.
• The pilot test script, so the model can be re-verified after a change.

This work sits alongside migrations on the Microsoft 365 migration page, which covers administrative segregation, and the wider identity and device baseline is on the infrastructure and security page.

FAQ