How CIPP Evaluates Roles
How CIPP decides a user's effective permissions when they hold multiple roles
CIPP assigns access through built-in roles and custom roles, and a single user can end up holding several of them at once — especially when roles are mapped to Entra ID groups and a user is a member of more than one group. This page explains, in plain terms, how those roles combine into the permissions a user actually gets.
For instructions on creating roles and mapping them to Entra groups, see Adding Users and Managing Roles.
The mental model
Built-in roles are the ceiling. Custom roles are an explicit allow-list.
A built-in role (
readonly,editor,admin,superadmin) sets the maximum a user can ever do.A custom role is an explicit list of allowed permissions, scoped by tenant and endpoint. Paired with a built-in role it narrows that ceiling; used on its own it grants exactly what it defines — no more, no less.
Everything below follows from those two ideas.
Built-in roles: highest wins
Built-in roles rank from least to most privileged:
readonly → editor → admin → superadmin
If a user is a member of several Entra groups that map to different built-in roles, they do not add together — the single highest role wins. A user who is both editor and readonly is simply an editor; the readonly membership contributes nothing.
readonly
Read/list only. No settings, no admin.
editor
Read and write, except system settings and Standards.
admin
Everything except a small set of super-admin-only settings.
superadmin
Everything, including high-privilege settings.
admin and superadmin ignore custom roles entirely. If any group grants a user admin or superadmin, they receive the full built-in permission set and every custom role on that user is disregarded. You cannot use a custom role to restrict an admin — assign editor or readonly instead and filter from there.
Custom roles: an explicit allow-list
A custom role is a hand-built list of permission categories — each set to None, Read, or Read/Write — optionally scoped to specific tenants (Allowed/Blocked Tenants) and with specific endpoints blocked (Blocked Endpoints).
Any permission category you do not explicitly set is a deny. An unset category is treated exactly as if you had selected None: the user is denied that permission. To let a user keep a capability, you must set that category to Read or Read/Write in the custom role — leaving it blank removes it.
How a custom role behaves depends on whether the user also holds a built-in role.
With a base role (editor or readonly)
editor or readonly)The built-in role sets the ceiling and the custom role narrows it down:
The user can do only what the base role allows and the custom role explicitly grants.
A custom role can never raise a user above the ceiling. Granting
Read/Writeto areadonlyuser still results in read-only access, becausereadonlyis the ceiling.Tenant and endpoint scoping from the custom role applies on top.
Without a base role (custom roles only)
If the user has only custom roles and no built-in role, the custom roles apply on their own:
Their access is exactly what the custom role explicitly grants — nothing more, nothing less.
There is no built-in ceiling, so base-role exclusions (such as system settings or Standards) do not apply. A custom role grants precisely what is defined in it, so scope these roles carefully.
Multiple custom roles on one user
If a user holds more than one custom role, their granted permissions are combined — a union, most permissive wins. If they also hold a base role, that ceiling still caps the combined result.
Tenant scope is evaluated per custom role, not pooled across them. For any single action, one custom role must grant both the required permission and access to the target tenant. A user cannot borrow the permission from one custom role and the tenant access from another.
Worked examples
Example 1 — Built-in roles only
Jane is a member of two Entra groups:
CIPP-Editors→ mapped toeditorCIPP-Read→ mapped toreadonly
Result: the higher role wins, so Jane is an editor. The readonly membership changes nothing.
Example 2 — Built-in role + custom role
Mark is a member of two Entra groups:
CIPP-Editors→ mapped toeditorCIPP-Helpdesk→ mapped to a custom role that grants Identity: Read/Write only, with Allowed Tenants = Contoso
Result: editor sets the ceiling (read/write everything except settings and Standards). The custom role filters that down to only Identity read/write, and only for Contoso. Net effect: Mark can manage users in Contoso and nothing else.
If Mark were removed from CIPP-Editors, the custom role would then apply on its own — he would keep exactly the permissions it defines (Identity read/write on Contoso), just with no editor ceiling shaping the result. See Example 4.
Example 3 — Admin plus a restrictive custom role
Sara is a member of two Entra groups:
CIPP-Admins→ mapped toadminCIPP-Helpdesk→ the restrictive custom role from Example 2
Result: admin wins outright and the custom role is ignored. Sara has full admin access. To actually limit her, remove the admin mapping and give her editor (or readonly) plus the custom role.
Example 4 — Custom roles only (no base role)
Priya is a member of one Entra group:
CIPP-Reporting→ mapped to a custom role granting Reports: Read and Identity: Read, Allowed Tenants =AllTenants
She is not in any group that maps to editor, readonly, admin, or superadmin.
Result: with no base role, the custom role applies on its own. Priya gets exactly Reports read and Identity read across all tenants — and nothing else, because every category she was not granted is a deny.
If Priya were also added to a second custom role granting Endpoint: Read, her access would be the union of the two: Reports read, Identity read, and Endpoint read.
Quick reference
Several built-in roles
The single highest role.
admin or superadmin (+ anything)
Full built-in access; custom roles ignored.
editor/readonly + one custom role
Built-in ceiling filtered down by the custom role's permissions, tenants, and blocked endpoints.
editor/readonly + several custom roles
Union of the custom roles' grants, still capped by the built-in ceiling; tenant scope checked per role.
One custom role, no base role
Exactly what that role explicitly grants — no ceiling. Unset categories are denied.
Several custom roles, no base role
Union of all the roles' explicit grants; tenant scope checked per role.
Because admin/superadmin bypass custom roles, the most common pattern for scoped access is to map a base role (editor or readonly) to one Entra group and a custom role to another, then add users to both — the base role provides a safe ceiling and the custom role tailors it. Custom-roles-only assignments also work, but without a base-role ceiling they grant exactly what is defined, so review them carefully. See Custom Roles for the full setup steps.
Feature Requests / Ideas
We value your feedback and ideas. Please raise any feature requests on GitHub.
Last updated
Was this helpful?

