Other posts by Jasper about the modern SharePoint experience:
You all know by now that I really love SharePoint—it shaped my career and allowed me to meet fascinating and lovely 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 Office 365 SharePoint permissions structure that are likely to cause adoption and governance issues for businesses. To understand this new permission structure, we first need to talk about Office 365 Groups.
Office 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:
An Office 365 group is a security group within Azure Active Directory.
IT understands this explanation immediately, but it’s far too technical for the regular business user. Here’s how I define it for them:
An Office 365 group enables teamwork for a group of people with a shared purpose, such as a project, a department or a team.
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 PowerBI 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, Yammer, SharePoint, Stream, PowerBI). 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.
The impact of Groups privacy settings on SharePoint team sites
An Office 365 group can be assigned one of two privacy settings:
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 (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 Next we can assign owners and members.
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 modern SharePoint team site has been created. That’s because the modern 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:
How do Office 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 Regional Collaboration Members group:
Where is Pavel? I added him earlier as a member. What you’re looking at here is the security group in Azure Active Directory. That’s what an Office 365 group is, remember: a security group in Azure Active Directory. Let’s take a step back and open the Office 365 Administration Center to view the group:
All four people I added while creating the team site are now members of the Regional Collaboration Office 365 group. Anne, Garth and I (as the team site’s creator) are the owners. Let’s head back to the SharePoint team site and open the Regional Collaboration Owners group:
Empty! That doesn’t make any sense, right? You would expect the three owners we just mentioned to be displayed here. This is because the owners we specified during the creation of the SharePoint team site were only added to the Office 365 group, as shown in the Office 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:
Modern 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, Pavel, 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 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 Office 365 group. That’s definitely possible. Again, this is where the usability of showing the Office 365 group and SharePoint members falls short. I’ve seen many people go straight to Add members:
Doing the above will add Belinda to the Office 365 group, not to the SharePoint team site. For that, you need to select Share Site Only under Site permissions:
Now Belinda will only gain access to the SharePoint team site and not to the whole Office 365 group.
How to adopt and govern modern Office 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 Office 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 Office 365 group members; I’d rather see the SharePoint team site members displayed here. The Office 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!
The full journey of the modern SharePoint experience is here. Stay tuned for the full series:
Modern SharePoint permissions (you are here)
SharePoint Modern Lists (coming soon)
SharePoint Modern Pages (coming soon)
SharePoint Modern Team Site (coming soon)
SharePoint Modern Publishing Site aka Communication Site (coming soon)
SharePoint Modern Search (coming soon)
Adopting and Governing the SharePoint Modern Experience (coming soon)
Pro tip: Click Subscribe below to be the first to know when a new article from the series has been published. You’ll also gain access to tons of useful resources and master tips every month!