Microsoft SharePoint Permissions haven’t really changed much over the years, but have SharePoint Online Permissions in Modern Sites changed?
There are certainly a lot of changes occurring in Microsoft SharePoint Online, including the way that we create SharePoint Team sites which has a knock on effect to how we will be managing SharePoint permissions in the not too distant future. These changes to SharePoint Online and SharePoint 2019, certainly need to be planned for and understood before we see organizations running into new SharePoint Permission challenges.
If you would like to understand the basics of SharePoint Permissions, then there are several posts that I have authored in the past which can be found below. However, this post is going to focus purely on the Modern Team site experience and in relation to SharePoint permissions moving forwards.
Blog Post: SharePoint 2016 Permissions Guide
Blog Post: How to Manage SharePoint Permissions in Bulk to Save Time
If you are using SharePoint Online Classic sites, you won’t notice a great deal of difference in the way that permissions have worked ever since SharePoint On-Premises 2013. The biggest change that occurred with SharePoint 2013 Permissions was that the Edit permission level became the default permission level for the Members group. SharePoint Sites, Lists and Items also had a new Share feature that has been with us through SharePoint 2016 On-Premises as well as SharePoint Online. Of course SharePoint Online also introduced External Sharing which has also been with us for quite some time now. So, let’s focus on SharePoint Online Permissions in Modern Sites specifically.
First of all, the way that we create sites has changed. In the past, there was a lot of planning involved if we were going to create a new site. Do we create it as a new root site in a site collection (site), or as a sub site (web) to an already existing site? If we create it as a sub site, do we inherit permissions from the parent, or do we create the site with unique permissions and carefully consider which groups will be required? If you didn’t carefully plan or consider these options, permissions inheritance and groups got messy very quickly! Users with Edit permissions could innocently share a team site, without realising that other sites that inherited the permissions or shared the same groups would also be affected, meaning that you actually shared a great deal more than you thought you had! Not only that, you just gave the user Edit permissions which means that they can share the content too!
This complexity has been simplified with modern team sites. In order to create a modern site, upon logging into SharePoint Online, you’ll see the “Create Site” link. Upon clicking “Create Site”, you are given the choice of a Team Site or a Communication Site as shown below:
Screenshot to show the selection of a Team Site or Communication Site
There is no question as to where this site will be created. Effectively, it is just a site, and the consideration of where in the site collection it will be placed, and whether it will inherit permissions has all gone. You’ll simply create a site, and not really need to care about where it is created. That means, that we don’t need to care about accidentally giving permissions to users through a lack of permission inheritance understanding. We simply decide on two things. Will this be a private or public site? If it is private, then who will be the owners of this newly created site, and who will be members? This granting of owners and members is illustrated in the screenshot below:
Screenshot to show setting the newly created site as a Private or Public Site
You may be wondering, if we don’t care where the site is created, then what about navigation? Well that’s where Hub sites come in. You can read more about Hub Sites here: https://lightningtools.com/blog/sharepoint-hub-sites/
Upon choosing to create a private site, you will be prompted to give additional permissions to your users. The wording “Additional Permissions” is used, because already you have just created a new Office 365 group, and therefore a groupified site. Meaning that controlling who gets membership to this site can easily be controlled, by simply adding users to the Office 365 Group. This really is decentralizing permissions management and putting users in control of who can see their content. Now, if this was a classic site with subsites, I would have a huge issue with the fact that users are so easily granting other users Edit permissions through the members group. But my main issue with that, was due to the fact that sub sites existed, and the same user would obtain permissions to a lot more content than anticipated. With this new model, sub sites are discouraged, so that shouldn’t be a problem. We really are just dealing with who has access to the content within this specific site.
Screenshot to show granting additional permissions
Historically, at this point, we may be deciding how we go about giving additional users permissions. One easy way to do that, is to nest an Active Directory Security Group within the Owners, Members or Visitors groups within your team site. However, you cannot assign an Active Directory Security Group as a member or owner of the site using this particular screen. That’s not to say it cannot be achieved at all, but specifically using this simplified modern way of assigning members or owners, you cannot nest an Active Directory Security Group, or another Office 365 Group for that matter. You literally are just adding a user by the username or email address. Therefore, it would appear that the encouragement is to plan to use Office 365 groups that are unique to the site. This makes controlling membership easy, and also means that we get rid of that issue of not being able to enumerate and view the membership of AD Security Groups through the SharePoint user interface.
So, now we have our new modern SharePoint Team Site created, how do we view the permissions assigned to it? In classic sites, there would be quite a few steps. We’d choose Site Actions, Site Settings, and then Site Permissions. Reporting on an item’s permissions was hideous! It took around seven clicks to get to the permissions page. Now, in a SharePoint Online Modern Site, we simply click Site Permissions from the Site Actions cog as shown below:
Screenshot showing a SharePoint Online modern team site and the Site Permissions link
Whether that link is useful or not, really depends on whether you are adopting this new simplified way of granting permissions, or whether you are planning on using the classic way of assigning permissions. Clicking the Site Permissions link will show you the Owners, Members and Visitors as well as offer you the ability to invite others to the site. Inviting others can be done in one of two ways:
Screenshot showing the Site Permissions
1. Add users to the Office 365 Group associated with the site therefore giving the user membership with Edit permissions
2. Share the site only.
The latter option gives you more control than the initial page upon site creation. By clicking Share the site, we can now grant permissions using our Active Directory Security Groups! Using the Share the Site Only option also means that the users within the AD security groups, or individuals, will only gain access to the site itself, and will not benefit from the Office 365 Group membership. Having this simplicity, but still control, I have to say is a huge improvement to SharePoint permissions management.
Screenshot showing the Share the Site Only option and successfully adding an Active Directory Security Group
You can of course, still access the classic permissions page by clicking the Advanced Permissions link shown in two screenshots above. This gives you the granularity and control that you have always had in SharePoint.
Screenshot showing the Advanced Permission Settings
So what about your SharePoint Modern Lists, and Libraries? This is an area where users who are already experienced with the classic SharePoint UI, are going to be confused in my opinion. The Share button is still there on the Edit Control Block, and also in the toolbar above the list/library. However, clicking it leads to some confusion.
Screenshot showing how to Share a list/library or item.
The behaviour of Sharing an item has not changed, but the user interface has. It certainly looks more modern. But the UI describes sending a link to a user. In this case, if the user does not already have permissions to the folder or item in any other way, the permission inheritance is broken on the item, and a link is sent to the user. The user in question, then received Edit permissions directly. Now this is good and bad. It’s a good thing, because I only chose to share an item and therefore the user does not get permissions to anything else in the site and isn’t a member of any groups whereby they would receive permissions to unintended content. What appears to be new here, is that the user is shown as having Edit permissions rather than Contribute upon sharing an item. (If you read on, you’ll find that this is not the case). The only reason that I dislike this behaviour, is that there will be many items with broken permission inheritance, and therefore it becomes difficult to manage permissions on all of these items should the user leave the organization. How do you possible find all the items where a user was granted permissions?
Screenshot showing how to share a link to an item.
Going back to the item to check who has permissions to it is obscure. You need to click the ellipsis and choose Manage Access which does not appear to be obvious.
Screenshot showing the Manage Access link
What I really like, is that upon clicking Manage Access, you can very easily remove the unique permissions or even change the level of permission that was granted from Edit to View as shown below:
Screenshot showing how easily permissions can be removed or modified
The extremely confusing factor is that the above screen shows Sara Lonsdale as having Edit permissions, when in fact she only received Contribute. Something Microsoft really needs to fix as this will lead to confusion.
Screenshot showing Contribute was assigned to the user, and not the implied Edit
Overall, I think Microsoft have done a fantastic job here. Permissions have always led to confusion mostly due to an overly complicated user interface. Microsoft have kept the way that permissions work the same, but carried out improvements by hiding the complexity and introducing Office 365 Groups. What you need to consider, is how you plan to educate your users on the changes to site creation, Office 365 group creation and the management of those groups, and what happens when you Share!
<Brett/>
We hope this information is useful to you. Setting permissions incorrectly in SharePoint can be disastrous for some. Put your mind at rest by using a permissions management tool such as DeliverPoint, available for either SharePoint Server or SharePoint Online.
