SharePoint permissions can be confusing. They can be especially daunting if you're trying to understand why there are differences between how they work in a classic site, a modern team site, and a communication site.
In this guide, we'll first look at the anatomy of permissions within SharePoint. Once we’ve covered the moving parts, we'll then look at the connection to Microsoft 365 groups and Active Directory, and how this relates to the differences between modern team sites and communication sites. Following this, we'll delve into a few example scenarios, and finally we'll cover a few common snags you need to look out for.
The anatomy of SharePoint permissions
Let's start with the three main components which make SharePoint permissions work:
- SharePoint permission levels
- SharePoint groups
- SharePoint objects
Component 1 - SharePoint permission levels
SharePoint permission levels are definitions of what someone can and cannot do within a SharePoint site. Permission levels in turn contain a combination of individual granular permissions in the categories List Permissions, Site Permissions and Personal Permissions.
As an example, the Edit permission level contains the granular permissions shown below.
The standard permission levels you'll find within a SharePoint site are:
- Full control - Can control all aspects of the site
- Design - Can view, add, update, delete, approve, and customize (this is a legacy level used in Classic sites)
- Edit - Can add, edit and delete lists; can view, add, update and delete list items and documents
- Contribute - Can view, add, update, and delete list items and documents
- Read - Can view pages and list items and download documents
Not all of these permission levels are always used. For example, in a standard modern team site, only Full Control and Edit permissions are assigned by default.
Component 2 - SharePoint groups
All SharePoint sites contain three SharePoint groups by default. These groups enable you to bundle users (and in some instances other groups) together to give them access to the site as a whole, to specific lists or libraries, folders, or even to individual items. The default groups you'll find in all sites are:
- Site owners
- Site members
- Site visitors
(These groups are used differently depending on whether it's a team or communication site, but we'll get to that later).
So what are site collection administrators?
Normal SharePoint groups can be renamed, their permission level changed, or even removed, but Site collection administrators is a fixed group which exists in all SharePoint sites and cannot be modified or removed. As a fixed rule, users or groups who are part of the Site collection administrators group always have the highest level of access possible on a site.
Component 3 - SharePoint objects
Within SharePoint, various types of containers and items within those containers can be created. Some of these objects can be nested within each other, some not. The objects most interacted with are:
- Sites
- Libraries in the form of Document Libraries, Pages Libraries, Asset Libraries, Picture Libraries
- Lists
- Folders inside libraries, or inside other folders
- Items in the form of documents, pages, images, videos or other files
How do these components fit together?
In short, this is how SharePoint permissions work: You grant a group or user a permission level or specific granular permissions to a SharePoint object. That's it.
Of course, there are many different permutations of this basic mechanism, but the same principle applies across the board. There is only one exception which we've already mentioned: Site collection administrators always have full control of the site, neither the permission level nor what it applies to can be changed for this group.
How does permission inheritance work?
When permissions are granted to a SharePoint object, they automatically apply to all the object's children, as long those children have not had their inheritance broken from their parent.
You can use the stop inheriting permissions button to stop an item, folder, library, or list from inheriting permissions from its parent object. When you stop this inheritance, you can apply unique permissions to the object, and any changes to the parent permissions will not affect the object's permissions anymore. Very importantly however, any changes you make to the object's permissions will affect its children.
Confused? Let's look at an example: Imagine you have document Y nested inside folder X.
In the default inherited state, any changes made to Site A (eg giving a specific individual edit permission) will apply to all the objects all the way down.
But when you stop inheriting permissions at the Folder X level, this happens:
- Immediately afterwards, the permissions for Folder X and Document Y are the same as they were before.
- As soon as you make a change to the permissions of Folder X, the new permissions will also apply to Document Y.
Stopping permission inheritance is something which should be done very carefully with thorough planning. It has the potential to cause confusion and accidental visibility of sensitive information to people who should not have access. This being said, there are indeed scenarios where it's useful to be able to display and hide information with increasing sensitivity as you drill into a structure, and where uninherited permissions have a place.
What is a Microsoft 365 group?
When Microsoft designed the 365 suite, they needed a way for teams who work together to easily grant and manage access to multiple services. For example, when a team of people get together to work on a project, they might need a team in Microsoft Teams, an accompanying SharePoint team site, a plan in Planner and a shared email address.
Microsoft 365 groups are the glue which binds all these services together and gives group owners a way to easily add and remove people from having access to multiple services.
How are Microsoft 365 groups and team sites connected?
In the SharePoint world, a Microsoft 365 group is the primary way to manage access to a modern team site. It gives group owners the ability to add and remove members and other owners using a simple membership panel (the panel you see at the top right of a team site).
But how did these members get here?
When a modern team site is created, this is what happens:
- The team site itself is created in SharePoint.
- A linked Microsoft 365 group is created.
- The Microsoft 365 group's owners and members are placed in the site’s SharePoint groups
This is where the owners and members are placed:
- Group owners are put in the SharePoint site owners group.
- Group owners are also put in the Site collection administrators group.
- Group members are put in the SharePoint site members group.
- The SharePoint site visitors group stays empty. This is because team sites are designed to be primarily collaborative workspaces where everyone can edit content.
Effectively, this happens:
When you use the members panel in your site to change the role of a user between being an owner or a member, you are directly changing their membership role in the Microsoft 365 group. This affects the access they have not only in the SharePoint site, but to any other Microsoft 365 services and resources connected to the group.
How do team site and communication site permissions differ?
As we’ve seen in the previous section, managing access to a modern SharePoint team site is easy, you can do most of it using the membership panel.
But what about communication sites? In permission terms, they work mostly like classic (old-style) SharePoint sites and are not Microsoft 365 group-connected. This means that SharePoint communication site permissions are managed by directly adding groups and users into the site’s SharePoint groups.
The practical implications are that:
- There is no membership panel which makes it easy to add and remove people, and we can’t quickly see how many members the site has.
- To make someone an owner or member of a communication site, we need to add them into one of the SharePoint groups using the Site settings > Site permissions menu.
- When we create a communication site from the SharePoint home page, the default permission action is that we’re directly (not as part of a group) put into the Site Collection Administrators and Site Owners groups. The Site members and Site visitors groups are empty and people need to be added to them before anyone else can access the site.
- Communication sites are intended to be edited by a small group of users who publish information for larger groups of users to view, so we need to populate the Site members and Site visitors groups to serve this purpose.
How does the “Privacy settings” option affect permissions?
When you create a team site, you have the option to select whether the site is public or private.
This is how the permissions are affected:
- Private – The members of the connected Microsoft 365 group are added to Site members group like we’ve already covered.
- Public – In addition to the members of the M365 group, all internal users on the tenant (Everyone except external users) are also added to the Site members group. This means that anyone in the tenant can access and edit the contents of the site. It’s important to understand that this does not yet give everyone access to Microsoft 365 group’s resources, it only 1) grants permission to the site itself and 2) allows everyone to add themselves (and others) to the group itself as members if they wish. After they’ve been added, they gain access to the group’s resources.
How does individual sharing affect team site permissions?
In an ideal world, we’d set up a team site’s permissions with a logical set of owners and members which are listed and neatly managed and the configuration would stay this way like we’ve already shown.
In reality, requirements change all the time, people change all the time, and people do things without realising the repercussions.
One of the risks of the openly collaborative nature of team sites is that it’s very easy for group members to use the Share this item button to share the contents of a team site with someone outside the current group, even if the group owners intended for the site to remain accessible only to the group itself.
If the contents of a site need to remain accessible only to the group, one of the actions we can take as owners is to use Site settings > Site permissions > Change how members can share to limit the sharing capabilities of members.
Non-standard SharePoint team site permission scenarios
Most people create a SharePoint team site in two ways:
- By creating a new team or private channel within a team (see Does Teams use SharePoint?)
- By using the standard Create site button on the SharePoint landing page.
In these scenarios, the defaults we’ve described so far apply. But what about more intricate scenarios commonly found out in the wild? The SProbot team sometimes sees organisations structuring permissions in these ways:
- Team sites used as publishing/communication sites by adding Everyone except external users into the Site visitors group. This approach is acceptable if the team site contains a combination of private and public content, but it’s very important that all members need to be acutely aware of this to prevent accidental publishing of sensitive information public areas of the site. Ideally, public and private information should rather be put in completely separate containers (read: split between communication and team sites), but this scenario makes sense if the goal is to reduce the number of top-level sites.
- Microsoft 365 groups are used to manage visitor access instead of editing access by moving the M365 group from the Site members group to the Site visitors group, and then managing editing access by directly adding individual AD users into the Site members group. In the scenarios we’ve seen this, the intention was to easily manage a large group of visitors using a Microsoft 365 group. In most instances, this task is better suited to a security group (dynamic security groups work well for this purpose) because it’s not possible to the group’s access to other group-connected services in the same granular way as it is in SharePoint.
Common SharePoint permission snags
With any complex application such as SharePoint, it’s easy to get things wrong sometimes. Here are some of the mistakes people commonly make with team site permissions:
- Making someone an owner and not realising that this makes them an owner of all resources the Microsoft 365 group is connected to.
- Adding too many group owners. When you have a group of 16 owners, who really accepts responsibility?
- Only having a single group owner. This is also a problem, because site management can easily fall by the wayside if the person suddenly leaves the company.
- Using AD groups everywhere, without visibility by business users. AD security groups (especially dynamic ones) are powerful tools which work well in many scenarios, but they remove visibility and control from the business/end-users themselves and move it to IT. If your organisation’s goal is to reduce IT management overhead and delegate management of groups to power users, centralising control within AD is something you should do very carefully.
- Adding someone directly to the SharePoint site members group instead of the connected Microsoft 365 group. When the Microsoft 365 group membership changes, they are left behind. It’s quite common for the Site owners, members and visitors groups to contain a mix of individual users and the standard Microsoft 365 groups, but this can get confusing and it’s not recommended unless you cannot avoid it.
Some of these snags can be avoided by using purpose-specific templates and applying governance rules to them, but as with most things, it all comes down to one thing: education. Keep sharing knowledge with your users, and they'll learn (people are smart!) and lighten the load on your admin capacity.
