SharePoint groups and permissions were for a long time the only permission system for SharePoint. When Microsoft introduced the Microsoft 365 permission system a few years ago, many things changed—slowly but steadily. Granting permissions became easier, and these then became valid for all Microsoft 365 applications. Today many people don’t know the SharePoint groups and permissions at all anymore. Are they really no longer relevant in today’s work environment and projects? Read on to learn more about why and when SharePoint permissions are still a good choice for your project.
SharePoint’s Permission System Has Proven Itself
SharePoint was launched in 2001 and has always had its own permissions system. I first came into contact with SharePoint in 2010 when I took over the PMO of a major program and was given responsibility for a SharePoint site and almost cut my teeth with SharePoint groups and permissions. As a new SharePoint site admin, It takes some time to understand the permission system and see the benefits in it. With its own and very versatile permission system, SharePoint has many advantages in project management, especially when it comes to better protecting certain data.
As an admin of a SharePoint site, it is essential to understand the SharePoint permission system and also how the Microsoft 365 permission system works in parallel here.
The Microsoft 365 Groups
Back in 2015, Microsoft has rolled out the new Office 365 functionality. They called it Office 365 Groups—beginning of 2020, they were renamed to “Microsoft 365 Groups”. The new functionality has provided a much-needed alternative to organizations looking to enhance collaboration. This is especially true with the many new Microsoft 365 applications that have been introduced in the last few years.
Microsoft 365 Groups is a cross-application membership service. Each Microsoft 365 Group lives in Azure Active Directory, has a list of members, and is attached to that group’s related Microsoft 365 workloads, including a SharePoint team site, Exchange mailbox, Planner, Whiteboard, Power BI, OneNote—and, optionally, a team in Microsoft Teams.
SharePoint Permissions Control Only the SharePoint Environment
SharePoint permissions only apply to SharePoint. But not for the many new Microsoft 365 applications that have been added in recent years and are important tools in our project collaboration. Of course, it is easier if the same permission groups can be used for all applications-and these are the Microsoft 365 Groups.
SharePoint, on the other hand, allows you to define additional user groups with specific permissions in addition to three standard groups: Owners, Members and Visitors. This granular assignment of permission can be an extremely useful feature in certain situations. Especially when libraries, lists, documents and data may only be viewed or edited by specific user groups. Here, the “need to know” principle is also an important topic.
Here’s a simple example: Only the members of your Project Management Office should have access to the contracts (SOW) with the contractors. To do this, proceed as follows:
- Ensure that the contracts are stored in a separate library, e.g. named “Contractor SOWs”.
- Break the inheritance of the permissions to this library
- Create a new SharePoint group named “PMO-Members”, give it the necessary permissions, e.g. Edit, and assign this group to the “Contractor SOWs” library.
- Delete now the existing permission groups in this library
You will notice that this simple use case would not have been possible with Microsoft 365 Groups and permissions only.
SharePoint and Microsoft 365 Permissions Complement Each Other Well
A big advantage is, you can use Microsoft 365 and SharePoint permissions together. With Microsoft 365 permission and groups you control e.g. access to all Microsoft 365 applications (incl. SharePoint). On SharePoint, you use SharePoint groups and permissions to control access to specific libraries or lists, e.g. specifically those with sensitive data that should only be accessible to certain people. As explained earlier, you do this by removing the permissions inheritance on these libraries or lists and then assigning them a newly defined group with specific permissions.. How exactly this works with the inheritance you can read here: How to Use Unique Permissions for Libraries and Lists in SharePoint (coming soon).
It is important for a site administrator in a project or program to have a good understanding of Microsoft 365 and SharePoint permissions in order to make the best use of them in their work environment. In this article I explain you in detail the difference between them: How to Use SharePoint Groups and Microsoft 365 Groups in Your Project Site
Here You Can Find More Knowledge
This was an overview of SharePoint groups and permissions and if they are still relevant and beneficial for collaboration in the project environment. What is your experience with SharePoint groups and permissions in projects? Do you agree with my statements or do you have a different opinion? Share your experience with the readers with a commentary so that we all get to know another view. Thank you!
Would you like to learn more about how to make your projects more successful with SharePoint? Save time and money and get firsthand experience with my book SharePoint Online for Project Management. It takes you an important step further!
Do you know somebody who might be interested in this article? Then simply forward it or share it. Thank you!