How much time it takes for inheritance effect to travel from parent folder to nested child files and folder in sharepoint.

Question

How much time it takes for inheritance effect to travel from parent folder to nested child files and folder in sharepoint.

Sweta Kumari 40

I have a use case where I need to remove inherited permissions from files and folders. To do this, I am using Microsoft Graph APIs to delete a permission from a parent folder.

I understand that the DELETE API call returns a success response (200/204) immediately after the permission is removed from the parent. However, I would like to know how permission inheritance propagation works for child folders and files.

Specifically:

After removing a permission from a parent folder, how long does it typically take for the change to be reflected across all descendant folders and files that inherit that permission?

Is the update effectively immediate, or is there an eventual consistency delay in the background?

For large folder hierarchies with many nested folders and files, is there any expected or documented propagation time?

Any insights or experience with permission inheritance propagation in Microsoft Graph / SharePoint would be greatly appreciated.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Please note that we're not Microsoft support, this is a user-to-user support forum. Moderators have no backend access and cannot directly intervene in Microsoft products. We provide only technical guidance and best-practice recommendations based on reported issues.

Hi @Sweta Kumari

May I ask you use did Graph endpoint to remove a permission, right?

DELETE /sites/{site-id}/drive/items/{item-id}/permissions/{perm-id}

Ref: Remove access to an item - Microsoft Graph v1.0 | Microsoft Learn

If yes, when you remove a permission from a parent folder via Microsoft Graph, the change is applied immediately to the parent object, and any child items that still inherit permissions will reflect that change logically without requiring a recursive propagation process, because they reference the same underlying permission scope (ACL) rather than storing independent copies.

SharePoint permission inheritance is based on ACL (permission scope) references rather than recursive propagation. Child objects inherit permissions by referencing the parent’s ACL, not by storing independent copies. As a result, when permissions are changed on a parent, all inheriting children reflect the updated permissions logically without a separate propagation process. Ref: Manage Permission Scopes in SharePoint - SharePoint in Microsoft 365 | Microsoft Learn

As a result, from the permission model perspective, the update is effectively immediate and independent of hierarchy size. However, it’s important to clarify that Microsoft documentation does not define or guarantee any exact delay, propagation time, or eventual consistency window for these changes, there is no published SLA or timing guidance for when the updated permissions will be fully observable in all scenarios.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Sweta Kumari 40 Reputation points

2026-06-17T07:39:29.0666667+00:00

Yes i used this endpoint to remove a permission.

DELETE /sites/{site-id}/drive/items/{item-id}/permissions/{perm-id}

Thank you for the clarification. My understanding now is that inherited child items reference the parent's ACL (permission scope) rather than maintaining separate permission copies. Therefore, removing a permission from the parent should be reflected immediately for all inheriting descendants, except those with broken inheritance. This helps clarify that there is no separate propagation process involved.
Jayden-P 26,280 Reputation points Microsoft External Staff Moderator

2026-06-17T07:41:15.01+00:00

Hi @Sweta Kumari

I'm glad my answer clarifies things up.

Answer 2

SharePoint permission inheritance is designed to apply changes from a parent object to its descendants as part of the same operation that breaks or restores inheritance. The documentation describes the behavior functionally, but does not provide or guarantee any specific propagation time or delay.

Key documented behaviors:

Permissions on securable objects (sites, lists/libraries, folders, items) inherit from the parent by default.
When inheritance is stopped (for example, on a list, library, folder, or item), SharePoint copies the groups, users, and permission levels from the parent to the child and then breaks inheritance. From that point, the child has its own permission scope and is no longer affected by changes on the parent.
When inheritance is restored, the child object again inherits users, groups, and permission levels from the parent, and any unique permissions on the child are lost.
A user can interrupt inheritance at the item level by sharing a document with someone who does not have access; SharePoint automatically stops inheritance on that document at that time.

The documentation also notes:

A permission scope is a uniquely secured object (unique ACL). Files and folders that inherit from the same parent share the same ACL.
SharePoint supports up to 50,000 unique ACLs per document library, with a recommended limit of 5,000 for best performance. This guidance is about performance and scale, not about a specific time window for propagation.

What is not documented:

There is no published SLA or documented “propagation time” for permission changes from a parent to all descendants.
There is no explicit statement of an eventual-consistency delay window for inheritance updates.

From the available documentation, the only safe, documented assumption is:

When a permission change is made on a parent that children still inherit from, the effective permissions for those inheriting children are updated as part of that operation. Any delay, if present, is not documented and not exposed as a supported or tunable parameter.
For large hierarchies, the main documented concern is the number of unique permission scopes (ACLs) and their size, because high counts can impact performance. However, no specific propagation timing is provided, even for large trees.

For scenarios that depend on precise timing (for example, immediately calling Microsoft Graph to evaluate effective permissions on many descendants), the recommended pattern is to:

Design to avoid excessive unique permission scopes (use inheritance and shared folders where possible).
Assume that permission changes on inheriting children are applied as part of the parent operation, but validate critical access paths (for example, by re-reading permissions or testing access) rather than relying on an undocumented fixed delay.

References: