Broken permission inheritance is one of the most common messes new SharePoint administrators inherit. Hundreds of items with unique permissions, no record of why they were set, and no quick way to see the full scope. Below is a direct comparison of the three main approaches for finding and fixing the problem.
| Method | Scope | Bulk repair | Requires PowerShell | Audit report first | Best for |
|---|---|---|---|---|---|
| SharePoint admin center | One object at a time | No | No | No | Isolated one-off fixes |
| PnP PowerShell | Scriptable across any scope | Yes (with scripting) | Yes | Manual scripting required | Dev teams with scripting capacity |
| ShareMaster | Site or site collection | Yes | No | Built-in export | Admins, consultants, bulk remediation |
What Broken Permission Inheritance Means in SharePoint Online
Every SharePoint site, library, folder, and list item inherits its permissions from its parent by default. When you break inheritance on an object, SharePoint creates a copy of the parent's permission set and attaches it directly to that object. From that point, changes to the parent no longer flow down to it.
Breaking inheritance is legitimate when you need different access on a specific thing: sharing a single project folder with an external client without exposing the rest of the site, for instance. The problem emerges when broken inheritance accumulates unchecked over months or years. The consequences:
- The admin center shows no tenant-wide view of how many items have unique permissions. The only way to see the scope is to open each library and check each item manually, or run a report.
- SharePoint must traverse more unique ACL entries when resolving access requests, which slows permission checks on large libraries.
- The 50,000 unique-permission limit per list can become a real constraint in libraries where individual items or folders each have their own access rules.
- After staff changes or org restructures, permission drift accumulates: the same user holds different access in different corners of the same site with no clear rationale.
Before You Start: Assess the Scope
The right repair method depends on how widespread the problem is. Running a quick assessment before choosing a tool saves time - a one-off permission fix needs a different approach than hundreds of items spread across multiple libraries. Three signals tell you how deep the issue runs:
- Number of items with unique permissions per library. Open a library in SharePoint and go to Library settings. The Permission Management section will tell you whether unique permissions exist on items, but not how many without a deeper report. PnP PowerShell or ShareMaster can produce the count quickly.
- Scope across the site collection. A problem confined to one library is a targeted fix. Broken inheritance spread across ten subsites and fifty libraries is a full remediation project requiring audit, stakeholder review, and bulk tooling.
- Compliance requirements. If your organisation is in a regulated industry or preparing for a Microsoft 365 Copilot rollout, the permissions audit report is often a deliverable in its own right before remediation begins. See the SharePoint permissions audit guide for the full process.
Option 1: SharePoint Admin Center
The SharePoint admin center and site-level permission settings pages let you view and reset inheritance for individual objects. Navigate to the item, library, or subsite whose permissions you want to fix, open its permission settings, and click "Delete unique permissions." SharePoint will restore inheritance from the parent immediately.
There is no bulk operation in the admin center. No report lists all objects with broken inheritance across a site. To identify affected items you must open each library, run its permissions report, and review each item row by row. For a site with twenty libraries and several thousand items, this is not a practical approach.
Use the admin center when:
- A specific user reports they have wrong access on a known file or folder.
- You need to confirm a repair worked after using a bulk tool.
- The affected site is small and has fewer than fifty items to review.
Option 2: PnP PowerShell
PnP PowerShell provides cmdlets to enumerate unique permissions and reset them in bulk. Get-PnPListItem with the -Fields parameter can retrieve the HasUniqueRoleAssignments property for each item in a list. Items where this is true have broken inheritance. Reset-PnPListItemPermission restores inheritance on an individual item; wrap it in a loop to handle an entire library in one pass.
A typical workflow for a single library:
- Connect to the site with
Connect-PnPOnlineusing a SharePoint admin credential or an app registration. - Retrieve all items with
Get-PnPListItem -List "Documents" -Fields HasUniqueRoleAssignments. - Filter for items where
HasUniqueRoleAssignments -eq $true. - Pipe each result to
Reset-PnPListItemPermission. - Write processed items and their prior permission state to a CSV file before resetting, in case you need a rollback reference.
Building and testing this script requires PowerShell proficiency and an understanding of SharePoint's API throttling behaviour. The script runs against one library at a time. Extending it to cover a full site collection with nested subsites adds significant complexity - scope the effort accordingly. PnP PowerShell is the right choice when your team already runs scripts in production and wants full programmatic control over every step.
See the full walkthrough in the step-by-step guide to fixing broken SharePoint permission inheritance, which covers both the PowerShell and GUI approaches in detail.
Option 3: ShareMaster Permissions Audit and Repair
ShareMaster's permissions tooling gives you a GUI-driven workflow that covers the audit and remediation in the same tool. Report Master generates an Excel-compatible permissions matrix showing which libraries, folders, and items have unique permissions versus inherited ones, along with who holds access and at what level. The export gives you a deliverable to share with management or a compliance officer before making any changes.
After reviewing the report, you select the items to remediate in ShareMaster's interface and run the inheritance reset. The operation runs through SharePoint's API directly from the desktop application. Progress is logged in real time. Because no scripting is involved, the process is accessible to admins who are not comfortable with PowerShell, and it scales to large site collections without the throttle-handling complexity that scripting requires.
This approach suits:
- IT administrators who need a permissions audit report before stakeholders approve remediation.
- Migration consultants cleaning up unique permissions before a cross-tenant site move, where broken inheritance can cause permission mapping errors in the destination tenant.
- MSPs running quarterly permissions reviews across multiple client tenants without building per-client PowerShell scripts.
- Compliance officers in regulated industries who need a signed-off audit artefact before any remediation action is taken.
For the complete remediation workflow, see how to remediate SharePoint permissions after an audit.
See Report Master permission audit featuresDecision Matrix: Which Approach Fits Your Situation?
| Situation | Recommended approach |
|---|---|
| Single item with wrong permissions, raised by a user helpdesk ticket | Admin center - navigate to the item and restore inheritance directly |
| One library, 50-300 items with unique permissions, no audit report needed | PnP PowerShell script or ShareMaster, depending on whether scripting is available |
| Multiple sites, 500+ items with unique permissions, audit report required before action | ShareMaster: generate the permissions matrix, review with stakeholders, then bulk reset |
| Pre-migration cleanup before a cross-tenant site move | ShareMaster: permissions report first to identify unique access that needs to be replicated or removed, then remediate |
| Automated scheduled monthly cleanup as part of a CI/CD pipeline | PnP PowerShell: integrate with Azure Automation or a scheduled task for recurring scripted remediation |
| MSP managing multiple client tenants, no PowerShell skills on the team | ShareMaster: GUI-driven, connects to each tenant in turn, no scripting required per client |
| Microsoft 365 Copilot readiness: ensure sensitive content is not over-shared before enabling Copilot | ShareMaster: permissions matrix export identifies over-permissioned content quickly at scale |
Frequently Asked Questions
What does broken permission inheritance mean in SharePoint?
In SharePoint, permission inheritance means a subsite, library, folder, or item inherits its permissions from its parent. When inheritance is broken, a unique permission set is applied directly to that object and it no longer follows changes made to the parent. Broken inheritance is often created intentionally to grant different access on a specific item, but it accumulates over time and becomes difficult to audit and manage at scale.
Is there a hard limit on unique permissions in SharePoint Online?
Yes. SharePoint Online supports a maximum of 50,000 unique permissions per list or library, where each instance of broken inheritance counts as one entry. Performance degrades well before the hard limit is reached. Libraries with thousands of items each carrying broken inheritance can become slow to load and difficult to manage. See the unique permissions limits reference for threshold details and performance guidance.
Does restoring inheritance delete the unique permissions that were set?
Yes. When you restore inheritance on a SharePoint item, library, or subsite, the unique permission set on that object is removed and the parent's permissions take over. Any custom grants that were applied specifically to that object are permanently deleted. Always produce an audit report and confirm with stakeholders before bulk-resetting inheritance, particularly on items that may have intentional access restrictions for compliance or confidentiality reasons.