Understanding SharePoint Permissions Inheritance

How to improve SharePoint Permissions inheritance

At the very start of my working life in SharePoint, back in 2005, I would run workshops for users trying to explain the concept of permissions inheritance. Back then, it was more focused on a Site Collection and how permissions are rolled down to the structure of sub Sites.  In the world of Modern SharePoint Sites, we now need to think about permissions inheritance in terms of Lists, Libraries, Folders and Documents.

What Exactly is Permissions Inheritance?

This is an important question: By default, when a SharePoint Site is created, all of the components within the Site have the same permissions as those assigned to the Site.  Typically, those permissions are based on three groups: Owners (admins); Members (editors); and Visitors (readers).  If for any reason you want to assign different permissions to one of the objects in the Site, then you can break permissions and adjust the permissions just for that particular object.

Breaking Permissions Inheritance Examples

Let’s place this in some context and consider a couple of practical examples of breaking permissions inheritance.  First, imagine an intranet Site where you want most users to read the content, but you have a specific library where they need to upload their expenses.  In this scenario, you would break inheritance and increase the permissions of the Visitors group just for this specific library.  Looking at it the other way, you may have a library containing documents that all users can read, but one folder contains sensitive documents which needs a restricted audience.  All you need to do is simply break permissions and remove the groups who should not have access.

Is Permissions Inheritance Really a Problem Anymore?

In modern SharePoint, Microsoft actively discourages the use of sub Sites, so is permissions inheritance a problem anymore?  The answer is of course, yes, because there is still a significant percentage of organisations using sub Sites.  Furthermore, there are plenty of use cases for the need to break inheritance for specific libraries, folders or content within a Site.  The examples above were just a couple of potential scenarios – and we are yet to even consider the unintentional breaks of inheritance.

Returning to the workshops mentioned at the beginning of this post – the thing most people struggled with was that breaking inheritance does not immediately change anything, and users will still have the same level of access at the Site.  Instead, changes made at the Site level will no longer roll down and the permissions of the specific object can be altered.

How to Manage SharePoint Permissions Inheritance

Organisations need to accept that there will probably be scenarios where objects in a Site require specific permissions.  However, it should certainly not be a free for all, and an appropriate approach needs to be put in place to ensure this privilege is limited to trusted users who understand any and all the consequences.  

There will however, always be scenarios where something goes wrong, and the challenge is then how to find those instances.  This is not always easy natively in SharePoint, especially where different objects in a Site have different permissions.  

Learn more about ProvisionPoint Permissions or book a free demo to see how it can simplify user permissions inheritance once and for all.