SharePoint Permissions Part 1 - Understanding Inheritance and Cascading

Photo by Jon Moore on Unsplash

SharePoint permissions are a common source of confusion and frustration.  This isn't because adding permissions for a new user is particularly difficult for an admin (although I'll cover one way to do that below), and nor is it because sharing a document with someone is particularly difficult for a user (although I'll cover that in a future article).  It's because it's very common to find yourself in a situation where you've given the correct permissions to a user, but they still can't see what you expect them to see.

Fear not though, because once you understand how permissions work you'll be able to fix your problems and prevent them happening in the future.  (Note: we'll be going through permissions for team sites - sites with lists and libraries - not Communications sites or the recently introduced Hub sites.  That's for a different time.)

To understand how SharePoint permissions work, you need to understand the hierarchy of objects, as well as inheritance and cascading.  

The hierarchy of objects in SharePoint is the equivalent of a family tree.  You have a node at the top (the parents), with nodes underneath (the children), nodes underneath them (the grandchildren), and so on. In SharePoint the hierarchy is:

The permissions for each of these nodes are inherited from the node above (the parent).  The Document node inherits permissions from the Folder node, which inherits from the Library node, and so on up to the Site Collection node. (If you're not using Folders then the Document node will inherit from the Library node.)

The converse of inheritance is cascading, that is, the permissions cascade down from the node above to the node below.  When you give a user permission to view a site, that permission cascades down to the library, then cascades down to the folder, then down to the individual documents.

Ok, so far so good: You create a site collection, give permission to people to view it, and they'll be able to view every site, list, library, folder and document underneath that site collection.

But that is the simplest possible option, and assumes a) that you don't need to give specific permissions to any particular object, b) that you won't give anyone else permissions to a specific object in the future and c) that no user will share a folder or document with anyone.  If any of those things happen then you'll find that the permissions aren't doing what you expected.

The reason for this is quite simple, and is at the heart of understanding SharePoint permissions: Giving unique permissions to an object breaks the inheritance.  

This means that if you, for example, give permissions to a user to see a specific library, the inheritance is broken.  So when you change the permissions in the site or the site collection, those changes won't cascade down to the library that has unique permissions.  Let's work through an example.

You create a site collection with yourself as Primary Site Collection Administrator.  Your site collection has one site, and 3 libraries called TestLib1, TestLib2, and TestLib3.  Each library has a folder called TestFolder1, TestFolder2, and TestFolder3 respectively, and each folder has a document called TestDoc1, TestDoc2 and TestDoc3 respectively.  Diagrammatically:

You give Alice and Bob edit permissions at the site level.  This cascades down to the nodes below, shown here as green nodes:

Alice and Bob have edit permissions to all of the green nodes.  If they - or you - add additional libraries, folders or documents then all 3 of you will be able to see the new objects, because the permissions will cascade down to those objects from the site.  

Now you decide to allow Charlotte to have access, but only to TestLib3.  This permission cascades down to the folder and document.  Charlotte's permissions are shown here as orange nodes:

Now Alice, Bob and Charlotte can all see TestLib3 and the folder and document underneath it, but only Alice and Bob can see TestLib1 and TestLib2.  

Now you give permission to Dave to the whole site - in other words, you want him to have the same access as Alice and Bob.  So you give him permission to see the site, and.....he can only see TestLib1 and TestLib2, and the folders and documents contained within them, shown in red below:

Why?  

Because by giving TestLib3 unique permissions - for Charlotte - you broke the inheritance, so permission changes at the site level will not cascade down to TestLib3.

Now imagine that Dave shared TestFolder1 with someone else in the organisation.  You give Ellie permission to the site, and her permissions are shown in purple:

Because Dave shared a folder (a very common action for users to perform), the inheritance for that folder is broken, and permission to it (and the document it contains) no longer cascades down.

To make matters more confusing, the inheritance that is working means that if Dave adds TestFolder1a to TestLib1, Ellie will be able to see it, because TestFolder1a will inherit permissions from its parent, TestLib1:

The situation now is that:

• Alice and Bob can see the site, all 3 TestLibs and the folders and documents contained in them.
• Charlotte can only see TestLib3 and the folder and document within it.
• Dave can only see TestLib1 and TestLib2, and the folders and documents within them.
• Ellie can see TestLib2, along with the folder and document in it, as well as TestLib1 and TestFolder1a, but not TestFolder1 and the document in it. 

Oh, and if you remove Alice's permissions by mistake, then give her those exact same permissions back....she'll have the same permissions as Ellie, because of all the breaks in inheritance.

It should be easy to see how complicated this can get.  At this stage you're already in a mess, and if you have an organisation with hundreds of users and a few sites, it's almost impossible not to get in this mess.  

However, there is a simple solution to stop this mess happening: Groups

If you give access to a group, then you can add and remove users from that group without breaking inheritance because the group always has permissions.  

To take a simple example, you might create a group that has Admin rights to the site and a group that has Edit rights to the site.  These permissions will cascade, and all lists, libraries, folders and documents will inherit those rights.  

In the example shown in the diagrams, you would be in the Admin group and Alice and Bob would be in the Edit group.  If you give Charlotte edit rights to just TestLib3, and then add Dave to the Edit group, he will now have access to all 3 libraries because he is a member of a group that already has access to them.  After Dave shares TestFolder 1, you add Ellie to the Edit group, and again she has access to all 3 libraries and all of the folders and documents in them because she is a member of a group that already has access to them.  

But if you then gave Frank edit permissions to the site as an individual, rather than adding him to the Edit group, he wouldn't be able to see TestLib3 (because you broke the inheritance when you gave Charlotte edit rights to it), nor would he be able to see TestFolder1 or the document in it (because Dave broke the inheritance when he shared TestFolder1).

So groups allow you to maintain your intended permissions no matter which user you add to them or in what order the users are added.  To add a group, go to Site Settings > Site Permissions and click Create Group in the ribbon.  However, you'll find that there are already a number of default groups there, as per this list from Microsoft, and you may find the the ones you want are already there.  You can delete any you don't need, or create any that you do.

It's common to just use the Owners, Members and Visitors groups, with Full Control, Edit and Read rights respectively.  This is something that Microsoft suggests, but it's by no means required.  Set up whatever groups you need!  If you want to know more about each of the default groups and what permissions they provide, there is a full list here, under the Default Permission Levels dropdown.

Next time we'll talk about using security groups to make your security both more robust and more manageable.