Entra ID custom roles

Microsoft Entra ID ships with over 100 built-in admin roles, covering most common scenarios. When the built-ins don't fit — your delegation model needs a specific subset of permissions that doesn't match any built-in — custom roles let you define your own.

Custom roles belong to the wider admin role design and are scoped with administrative units; the built-in roles they refine are listed in Microsoft 365 administrator roles, and PIM makes them just-in-time.

When custom roles make sense

Use cases where built-ins fall short:

• A helpdesk role that can reset passwords for users in their region (covered by administrative units combined with built-in roles), but also needs to add users to a specific group (which built-in roles don't always allow scoped).
• An application owner role for managing one specific enterprise app without admin rights over others.
• A read-only investigator role with specific audit-log access but no configuration permissions.
• A service-account-management role for IT teams managing service principals without other admin rights.

If a built-in role works, use the built-in role — custom roles add ongoing complexity. Reach for custom only when the built-ins genuinely don't fit.

How custom roles work

A custom role is a named set of permissions that can be assigned to users, groups, or service principals. Components:

• Resource permissions — which actions the role allows (read, update, delete on specific Entra ID resource types).
• Scope — at the tenant level or scoped to specific resources (an administrative unit, a specific application, a specific Microsoft 365 Group).

Available permissions are documented per resource type — users, groups, applications, devices, service principals, policies. The set covers most scenarios; Microsoft expands it over time.

Configuration

In Entra admin center → Identity → Roles & admins → Custom roles:

1. Create a new custom role with a descriptive name.
2. Add permissions by choosing from the catalogue.
3. Assign the role to users / groups, optionally scoped to a specific resource.
4. Test with a non-production identity before broader rollout.

Custom roles can also be managed via PowerShell and the Microsoft Graph for automation.

Limitations

Several constraints to know:

• Not every permission is available for custom roles — some sensitive permissions are built-in-only.
• Custom roles can't grant permissions outside of Entra ID — they don't extend to Exchange-specific or SharePoint-specific roles, which have their own role models.
• Cross-product permissions (Defender, Purview, Intune) have their own role systems that don't combine with Entra custom roles.
• PIM support is available for custom roles, but verify in Entra admin center for the specific role.

Operational discipline

• Naming convention — Custom: Description (Scope) makes them obvious in lists.
• Documentation — record why each custom role exists and who owns it. Future-you will thank past-you.
• Periodic review — re-evaluate whether each custom role is still needed; permission requirements drift.
• Avoid duplicating built-ins — if you're recreating a built-in role with slight tweaks, consider whether the tweak is really worth a separate role.

Alternatives to consider first

Before reaching for custom roles, consider:

• Built-in role + administrative unit scope — many delegation scenarios are best handled with built-in roles scoped to AUs.
• PIM with multiple eligible assignments — different time-bound roles for different scenarios on the same user.
• Entitlement management access packages — for resource-specific access rather than admin-role-style permissions.

Custom roles are powerful but should be the answer to "we tried everything simpler first." When they fit, they're elegant; when overused, they create governance burden.