Quick reference for SharePoint Online unique permission limits, inheritance scope, and when to use security groups instead of individual assignments.
| Scope | Hard limit | What happens at the limit |
|---|---|---|
| Role assignments per list or library | 50,000 | SharePoint blocks any new unique permission grants at item level until the count falls below the cap. |
| Unique permission scopes per item | 1 (one scope per item) | An item holds exactly one permission set at a time: either inherited or its own unique set. |
| Role assignments per site | No separate site-level cap | The aggregate of all role assignments across all lists within the site. Each list is capped independently at 50,000. |
| Inheritance depth | No hard cap on nesting levels | Performance degrades with many levels of broken inheritance; keep chains shallow where possible. |
How permission inheritance works in SharePoint Online
Every object in SharePoint Online (sites, libraries, folders, files, and list items) starts its life inheriting permissions from its parent. The full chain, from broadest to narrowest scope, runs in this order:
- Site collection - the root; permissions set here flow down by default to everything below.
- Site - inherits from the site collection unless broken; subsites inherit from their parent site.
- Library or list - inherits from its site unless broken.
- Folder - inherits from its library or list unless broken.
- Item (file or list item) - inherits from its folder, or from the library directly if no folder exists.
When you break inheritance on any object, SharePoint copies the parent's current permission set into a new, independent scope attached to that object. From that point, changes to the parent no longer flow down. Breaking inheritance at a folder level, for example, does not break it on the items inside the folder; those items continue to inherit from the folder.
Breaking inheritance can be reversed. Restoring inheritance removes the unique permission set and reconnects the object to its parent. Any custom permissions added while the object had unique permissions are discarded when inheritance is restored.
| Object | Default parent | Can break? | Minimum role to break |
|---|---|---|---|
| Site collection | (top level; no parent) | N/A | Site collection administrator |
| Site or subsite | Parent site or site collection | Yes | Site owner |
| Library or list | Site | Yes | Site owner |
| Folder | Library or list | Yes | Site owner |
| File or list item | Folder or library | Yes | Site owner |
Unique permission limits and performance thresholds
The 50,000 hard cap is rarely hit by accident in a normally managed library. It becomes a risk in libraries where item-level unique permissions are assigned automatically by workflow, or in large lists where every row gets individually permissioned.
Each time an item has unique permissions, SharePoint stores one or more role assignment entries for that item. In a library of 10,000 items each shared directly with three individuals rather than a group, the role assignment count hits 30,000 - approaching the cap before the library is even full. Switch to a security group as the grantee and the same 10,000 items produce 10,000 role entries, with membership managed in Entra ID.
| Scenario | Approximate role assignment count | Risk |
|---|---|---|
| 1,000 items, each uniquely permissioned to 1 group | ~1,000 | Low. Well within the cap; minimal performance impact. |
| 5,000 items, each uniquely permissioned to 3 users | ~15,000 | Medium. Noticeable slowdown on large list views; search indexing may lag. |
| 10,000 items, each permissioned to 5 users | ~50,000 | At the hard cap. No new unique permissions can be created in this list. |
| Same 10,000 items, each permissioned to 1 Entra ID group | ~10,000 | Low. Functionally equivalent access, managed at the group level. |
When to break inheritance vs when to use permission groups
Breaking inheritance is the right tool when a genuinely different audience needs access to a specific folder, library, or item. A project library restricted to the project team, a legal documents folder visible only to Legal, a single confidential HR file: these are all legitimate uses.
Using security groups (Entra ID groups or SharePoint groups) is the right tool for managing who is in that audience. Grant access to the group once, then manage membership in Entra ID. This keeps the role assignment count proportional to the number of unique permission scopes, not to the number of individual users.
The combination that performs best: break inheritance at the library or folder level (not at every item), and grant access to groups rather than individuals. This minimises the role assignment count, keeps the 50,000 cap safely out of reach, and makes bulk permission changes (onboarding, offboarding, organisational restructures) a matter of editing group membership rather than re-permissioning thousands of items.
Where unique item-level permissions already exist at scale, ShareMaster's Shared Links & Permissions tool lets you audit the full permission matrix, identify items with unique permissions, and remove sharing links or specific grants in bulk.