SharePoint Permission Inheritance

SharePoint uses a hierarchical permission model where permissions can flow from a parent object to its children. By default, when you create a new site, list, library, folder, or item, it inherits permissions from its immediate parent. For example, a document library inherits from the site; a folder within that library inherits from the library; a document within that folder inherits from the folder. This inheritance chain allows administrators to grant access at a high level (e.g., the site) and have those permissions apply to all content underneath, simplifying management.

Without inheritance, every new object would require manual permission assignment, leading to massive administrative overhead and inconsistency. Inheritance ensures that adding a user to a site group automatically grants them access to all lists, libraries, and items within that site (unless inheritance is broken). It also makes auditing and troubleshooting easier because you can trace permission grants up the hierarchy.

When inheritance is intact, child objects do not store their own permission entries. Instead, they reference the parent's permission set. When a user requests access to a resource, SharePoint walks up the hierarchy until it finds an object with unique permissions (or the root site collection). It then evaluates the permissions on that object. This means changes to a parent's permissions are immediately effective for all inheriting children.

When you break inheritance on a child object, SharePoint creates a copy of the parent's permission set at that moment and stores it on the child. From that point forward, the child has its own Access Control List (ACL) that is independent of the parent. Any changes to the parent's permissions do not affect the child, and vice versa. The child's ACL is a snapshot; it does not maintain a link to the parent. If you later restore inheritance (re-inherit), SharePoint discards the child's custom ACL and replaces it with the parent's current ACL. This action is irreversible—all custom permissions are lost.

Using SharePoint Online Management Shell:

# Connect to SharePoint Online
Connect-SPOService -Url https://yourtenant-admin.sharepoint.com

# Get site collection
$site = Get-SPOSite -Identity https://yourtenant.sharepoint.com/sites/yoursite

# Check permission inheritance for a specific web
$web = Get-SPOWeb -Site $site.Url
$web.HasUniqueRoleAssignments  # True or False

# Break inheritance on a list (using PnP PowerShell)
Connect-PnPOnline -Url https://yourtenant.sharepoint.com/sites/yoursite
Set-PnPList -Identity "Documents" -BreakRoleInheritance -CopyRoleAssignments:$true

# Restore inheritance
Set-PnPList -Identity "Documents" -ResetRoleInheritance

Using REST API:

# Check inheritance
GET https://yourtenant.sharepoint.com/sites/yoursite/_api/web/lists/getbytitle('Documents')/HasUniqueRoleAssignments

# Break inheritance
POST https://yourtenant.sharepoint.com/sites/yoursite/_api/web/lists/getbytitle('Documents')/breakroleinheritance(copyRoleAssignments=true)

# Restore inheritance
POST https://yourtenant.sharepoint.com/sites/yoursite/_api/web/lists/getbytitle('Documents')/resetroleinheritance()

A large enterprise has an HR site with a 'Confidential' document library that should only be accessible to HR managers. The rest of the HR team should have access to the site but not this library. The administrator breaks inheritance on the library, removes the default 'HR Members' group, and adds a new 'HR Managers' group with Contribute permissions. This solves the problem: HR team members can access the site but get an access denied error when trying to open the library. However, if later the administrator adds a new user to the 'HR Members' group (which has site-level permissions), that user will not gain access to the library because inheritance is broken. This is a common scenario where broken inheritance provides granular control.

A project management site collection has a top-level site with general project information. Each project team has its own sub-site. To keep management simple, the administrator initially inherits permissions from the top-level site. But one project (Project X) requires external vendor access. The administrator breaks inheritance on the Project X sub-site and adds the vendor's Azure AD guest account with Read permissions. This works well until the vendor's contract ends; the administrator then restores inheritance on the sub-site, inadvertently granting the vendor access again if the top-level site still has the vendor guest account. To avoid this, the administrator should remove the vendor from the top-level site before restoring inheritance, or keep unique permissions and manually remove the vendor.

In a large tenant with thousands of sites, breaking inheritance on hundreds of thousands of items can lead to performance issues. For example, a document library with 10,000 documents where each document has unique permissions (e.g., via sharing) will exceed the 50,000 unique permission scopes limit if not managed carefully. The SharePoint search index may also become bloated. Administrators must monitor the number of unique permissions using the 'Site Collection Storage Metrics' or PowerShell scripts. A common misconfiguration is breaking inheritance on individual items instead of using folders; folders are more efficient because they require only one unique permission scope per folder, not per item.