How broken are Microsoft 365 SharePoint permissions?

If you feel like SharePoint permissions in the modern Microsoft 365 experience aren’t as straightforward as they should be, you’re not alone.

I love SharePoint—it shaped my career and allowed me to meet fascinating people all over the world.

I never enjoy writing articles with a negative title like this one, but I’m committed to sharing my honest opinion on SharePoint and other Microsoft technologies.

And in this case, I believe there are flaws in the modern Microsoft 365 SharePoint permissions structure that are likely to cause adoption and governance issues for businesses. To understand this permission structure, we first need to talk about Microsoft 365 Groups.

Microsoft 365 Groups: creating an integrated collaboration experience

Office 365 is a collection of cloud services that, together, represent the building blocks of the modern workplace. SharePoint Online used to be an outlier, completely disconnected from its Office 365 brothers and sisters such as Exchange Online and Planner. This all changed with the introduction of Office 365 Groups (Groups).

I haven’t come across a single way to explain Groups that works for both IT and business audiences, so I came up with two separate definitions. Let’s start with what I tell IT professionals:

IT understands this explanation immediately, but it’s far too technical for the regular business user. Here’s how I define it for them:

Groups have been a blessing for the future of SharePoint Online within Office 365. SharePoint is fantastic for content management, but it tends to fall short when it comes to tasks like managing projects, inviting people to a shared calendar or providing business intelligence solutions—that’s where Planner, Exchange Online, and Power BI shine. Groups lets you connect all these services and relieve SharePoint of the stress of providing solutions it wasn’t designed for.

Now that we’ve covered the general background and purpose of Groups, let’s move forward to see where the permission issues start.

Groups permissions vs. SharePoint permissions

Groups have their own permission model that comprises the roles Owner and Member.

• Owners: manage the group (e.g. changing titles, managing members and privacy settings)
• Members: collaborate around content (e.g. conversations in Yammer and Outlook, documents within a SharePoint team site)

These two roles have a huge impact on connected services (Planner, Exchange, Teams, Viva Engage, SharePoint, Stream, Power BI). For example, a group owner will also be assigned the role of site collection administrator for the SharePoint team site. This doesn’t have to be an issue, but it’s definitely important to be aware of. Let’s see how else this can impact a SharePoint team site.

Enhance your learning on SharePoint permissions best practices and permissions levels for seamless collaboration within your organization.

The impact of Groups privacy settings on SharePoint team sites

A Microsoft 365 group can be assigned the following privacy settings:

• Public
• Private
• Org-wide

The choice you make here will affect the permission setup within the SharePoint team site. However, you’ll always have the option to switch back and forth between public and private (that’s a relief, no?). The default setting is Private, so let’s focus on that first.

Private SharePoint team site

The privacy settings show up when we create a SharePoint team site within SharePoint Home:

After clicking Team site, select a site template.

After selecting the site template, the next step is to assign a name, description, group e-mail, and URL to your team site.

Click on Next. Then, assign the sensitivity, privacy setting, and language before clicking on Create site. 

Then, you can assign members. And, when applicable, promote them to site owners. 

These aren’t just SharePoint team site owners and members; they’re also the group’s owners and members. That’s really important to understand: the owner/member permissions you assign when creating a team site also extend to connected services, such as Planner and Teams.

Things typically start to get confusing once the SharePoint team site has been created. That’s because the SharePoint team site interface shows both the owners and members of the Office 365 group and SharePoint team site membership. Group membership is displayed in the top right corner:

Let’s take a look at our members:  

Ok, these are the people I added while creating the SharePoint team site. Everything makes sense so far. Let’s move on to the three traditional SharePoint security groups:

• Owners
• Members
• Visitors

How do Microsoft 365 group permissions translate into SharePoint site permissions? Click the wheel icon and select Site permissions:

Under Site owners and Site members, only groups—not people—are displayed. For a business user, this can be confusing: “Where are all the people I added in the beginning? I can see them when I click on Members, but now they’re gone!”

You probably noticed the Advanced permission settings link. Let’s click it:

Hey, this looks familiar! Indeed, it’s the same permission settings menu we’ve been using since SharePoint 2007. Let’s open the Site Members group:

Where are Alex and Allan? I added them earlier as members. What you’re looking at here is the security group in Microsoft Entra ID. That’s what a Microsoft 365 group is, remember: a security group. Let’s take a step back and open the Microsoft 365 Administration Center to view the group:

Both Alex and Allan I added while creating the team site are now members of the Microsoft 365 group. Allan and I (as the team site’s creator) are the owners.

Let’s head back to the SharePoint team site and open the Owners group:

Empty! That doesn’t make any sense, right? You would expect the owners to be displayed here. This is because the owners we specified during the creation of the SharePoint team site were only added to the Microsoft 365 group, as shown in the Microsoft 365 Administration Center screenshot. That said, from a usability perspective, it would be useful to display the owners here as well so it’s clear to the SharePoint team site administrator who has owner permissions over their SharePoint team site. And the mess doesn’t stop there, unfortunately—it extends to member permissions as well:

SharePoint team site members are assigned Edit permissions by default. This contrasts with classic SharePoint team sites, where the default permission level for members was Contribute. There’s a significant difference between the two:

• Contribute: can view, add, update, and delete list items and documents.
• Edit: can add, edit, and delete lists; can view, add, update and delete list items and documents.

Thanks to their default Edit permissions, all members are free to create lists and libraries from the get-go. Giving that level of responsibility to everyone can have a huge impact on SharePoint team site governance and adoption. On one hand, I understand the reasoning behind this change: from a collaboration perspective, you want everyone to be on the same level in order to contribute without restrictions. Previously, people had to ask their SharePoint team site owners to create lists and libraries, but now they can get the job done a lot quicker.

On the other hand, this decision can lead to chaos. You now have to include working with document libraries and lists in the training you give regular business users. Fortunately, a number of changes have been made to lists and libraries in order to improve their user-friendliness.

In addition to creating lists and libraries, Alex, who is a member, can now edit the team site’s home page. That really annoys me—I only want owners to be able to edit the home page. The reason I find it annoying is because you have to increase the training content to business users who aren’t ready for such a responsibility. Most business users are already struggling with working with documents. Don’t even try to explain to them how to edit a home page. So, what are my options? I’d have to break the permissions of home.aspx and change the member permissions from Edit to Read. That’s a lot of hassle.

What about the permissions that govern the creation of lists and libraries? Are we at least able to change those? Nope. You can’t edit a member group’s permissions from Edit to Contribute. Again, I get the idea behind the new permissions structure, but it would be nice to have the option to switch between Edit and Contribute. Not every organization is ready to use this new, highly democratic model.

Privacy set to public? Be careful

Are you still with me? It’s quite the puzzle but hang tight. Next, we’ll take a look at what happens when we switch our team site from Private to Public. Ready?

Oh my. Edit is now the default permission for all internal users. That’s a lot of responsibility to give to everyone within your organization. Again, I do get it from a collaboration standpoint. But it still doesn’t make total sense to me: why does everyone need the ability to edit the home page and create lists and libraries? I would have preferred to have this set to Read by default.

Sharing the SharePoint team site

There are scenarios where you want to collaborate with colleagues within the SharePoint team site but not necessarily in other connected Groups services. For example, you might only want to collaborate within a set of documents in a document library, without having to make each collaborator a member of the Microsoft 365 group. That’s definitely possible. Again, this is where the usability of showing the Microsoft 365 group and SharePoint members falls short. I’ve seen many people go straight to Add members:

Doing the above will add Patti to the Microsoft 365 group, not to the SharePoint team site. For that, you need to select Share Site Only under Site permissions:

Now Patti will only gain access to the SharePoint team site and not to the whole Microsoft 365 group.

How to adopt and govern modern Microsoft 365 SharePoint permissions

Adoption-wise, the main challenge with SharePoint permissions stems from the default Edit permissions for members. You’ll need to educate your users on the new functionalities available to them (e.g. creating lists and libraries) and ensure they understand the connection between Office 365 Groups and SharePoint team site permissions. It isn’t the easiest concept to explain, but in the end, the end-user benefits should outweigh any initial struggles.

What does this mean for governance? Unfortunately, we can’t change member permissions from Edit back to Contribute. My advice would be to create a request process for modern SharePoint team sites and use it in conjunction with a site provisioning solution (check out the PnP provisioning framework). The site provisioning solution should change the permissions for everyone within the organization to Read instead of Edit.

There’s plenty of room for improvement

Although modern Microsoft 365 SharePoint permissions are, in my eyes, a huge challenge in terms of adoption and governance, I do see light at the end of this messy tunnel. With a few easy fixes, Microsoft could certainly turn this into a perfectly coherent experience for both users and admins—the foundation is already there. I would focus on two components:

• SharePoint site members overview
• Default Edit permissions

SharePoint site members overview

Business users really want to see the individual members in their overview.

The members you see in the above overview are Microsoft 365 group members; I’d rather see the SharePoint team site members displayed here. The Microsoft 365 group permissions could be moved to the Site settings, as they’re only really relevant for administrators anyway.

Default Edit permissions

This one is the easiest to fix: stop giving Edit permissions to SharePoint site members out of the box. Instead, set member permissions to Contribute by default, and allow owners to change them to Edit when it’s appropriate. Also apply this to public SharePoint team sites—we don’t necessarily want to give Edit permissions to everyone within the organization right off the bat. This should be set to Read until an owner decides to give members more leeway.

Rethinking our relationship with SharePoint

I focus a lot on SharePoint permissions, but I do want to urge everyone to start viewing modern SharePoint team sites as part of a bigger picture. SharePoint isn’t isolated anymore—it’s evolved into a connected solution for teamwork. Embracing this new purpose and working with group owners and members will make life easier for everyone involved. In a true teamwork situation, after all, you shouldn’t need to differentiate roles beyond Owner and Member. Coming from a classic SharePoint background, however, I’m fully aware that adopting this mindset is far easier said than done. We have to try!