We explain two ways to manage user and group permissions in SharePoint Online—ensuring the right people have access to the right things.
SharePoint online permissions are managed through a set of membership groups within some types of sites (owners, members, visitors, etc.).
We know, and Microsoft also knows, that secure collaboration is crucial when working online. You have a wide array of users with access to site content, and you need to make sure that the intern doesn’t somehow stumble onto the company’s secrets.
With SharePoint Online, you have a broader set of capabilities to secure collaboration in Microsoft 365 while giving your users more control.
Here at ShareGate, we enable you to implement SharePoint permissions best practices in one handy multi-tool.
In this article, we simplify the process of permissions management across different types of sites in SharePoint. By the end, you’ll get a clear picture of the flexibility you now have when looking to collaborate securely inside and outside your organization.
Table of contents
- What are SharePoint permissions?
- An overview of permission levels in SharePoint
- Best practices for permissions inheritance and breaking permissions inheritance
- Best practices for the principle of least privilege
- Best practices for simplifying SharePoint permissions management using groups
- 2 ways to manage user and group permissions in SharePoint Online
In a nutshell, SharePoint lets you grant permissions to users in SharePoint. But another important follow-up question would be, “How much can I play around with these permissions?”
To answer that question, it’s a good idea to first familiarize yourself with all of the kinds of permissions available in SharePoint. They include:
Team permissions: Depending on whether you add a user as an owner or a member of the associated Microsoft 365 group, permissions to the team site are assigned accordingly. When Dave is added as a team member in the group, he’s automatically a ‘member’ of the SharePoint team site rather than an ‘owner’ or ‘visitor’.
Communication site permissions: Unlike SharePoint team sites, communication sites aren’t part of Microsoft 365 Groups. Owners, members, or visitors added to a SharePoint communication feature are only associated with that particular site. Of course, different permission levels can be granted (as an owner, member, visitor, or custom SharePoint group) to a single user, security group, or an entire Microsoft 365 group.
Use case: Inviting visitors to a communication site for collaboration. Visitors can be added as part of a security group where permissions are standardized for a large number of visiting collaborators.
Hub site permissions: SharePoint admins control which users can add more sites. Hub permissions can go either of two ways:
- For team sites, permissions should be managed from the corresponding Microsoft 365 group.
- For communication sites, permissions should be managed from the SharePoint group (since communication sites aren’t part of Microsoft 365 Groups).
Shareable links permissions: Any user assigned permission to access a site, group, or team automatically has access to the corresponding SharePoint site data. Shareable links allow you to share specific data rather than the entire site content. You can edit permissions so that the shared link is accessible by everyone or specified users.
Guest sharing permissions: SharePoint allows guest-sharing capabilities to make collaboration with outside parties easier. Permissions can be edited so that only specific site data is accessible by outside parties.
An overview of permission levels in SharePoint
First, let’s have a closer look at all the permissions levels available in SharePoint:
|Permission level name
|Definition and usage
|When to use
|Grants complete control over the site and content.
Users with this permission level can create, modify, and delete lists, libraries, pages, and site settings. They can also manage user profiles and permissions.
|Should be given to team members responsible for site administration, including managing site structure, permissions, and overall governance.
IT admins/managers typically have this permission level.
|Grants users the ability to create lists, libraries, and pages.
Users with this permission level can modify the site’s appearance, apply unique styles, and edit the layout. They can also add, edit, and delete items within lists and libraries.
|Should be given to team members who need to create and edit the site’s structure and design.
Web designers and site architects typically have this permission level.
|Grants users the ability to add, edit, and delete items within lists and libraries.
Users with this permission level can contribute content and collaborate with others by modifying existing content.
|Should be given to team members who need to actively contribute and collaborate on the site’s content.
Project team members and content creators typically have this permission level.
|Grants users the ability to add, update, delete, and view list items and documents.
Users with this permission level can upload documents, and participate in discussions, along with being able to add, edit, and manage different versions of a document.
Note: Users with this permission level cannot tamper with site structure.
|Should be given to users who need to contribute content and participate in collaborative efforts without requiring administrative control or access to site settings.
Project team members and content creators typically have this permission level.
|Grants users the ability to view pages and items in lists and libraries.
Users with this permission level can download documents and view the content (but can’t modify any content).
|Should be given to users who need access to site content for informational purposes only.
Project stakeholders (can include people outside of your organization) and team members (like from different departments) typically have this permission level.
|Grants users the ability to access specific content within a site while restricting access to the overall site.
Users with this permission level can only work on the specific documents, folders, or items that they’re allowed to access.
|Should be given to users who only require access to specific content as part of the principle of least privilege to ensure effective security.
External collaborators and junior-level team members typically have this permission level.
|Grants users the ability to review and approve content, such as documents or list items.
Users with this permission level can also edit or delete items.
|Should be given to users who are part of the content approval process.
Managers, quality control personnel, and external stakeholders (such as clients) typically have this permission level.
|Grants users the ability to create and edit sites, pages, and other site components.
Users with this permission level can also create, edit, and delete permission levels, assign permissions to users and groups, and manage permission inheritance.
|Should be given to users responsible for managing the site’s structure, creating sub-sites, or managing navigation elements.
Site administrators and webmasters typically have this permission level.
|Restrict users from viewing historical versions of documents and list items.
Users with this permission level can still view current versions of pages and documents but cannot edit, delete or add new items.
|Should be given to users who need access to the most up-to-date content but should not view older versions or sensitive information.
External stakeholders (such as clients) and junior team members typically have this permission level.
|Grants users the ability to view pages, documents, and items but doesn’t grant any editing or contribution capabilities.
Unlike Restricted Read, users with the View Only permission level can view older versions of the pages, documents, or items.
|Should be given to users who require read-only access to content without the need to contribute or modify it.
External stakeholders (like clients) and junior team members usually have this permission level.
Best practice: Custom permission levels
On top of the existing permission levels that you have within SharePoint, you can use custom permission levels to tailor permissions management around your organization’s specific needs.
Keep the following information in mind about custom permission levels in SharePoint, and you’ll be all set:
When you create custom permissions
Administrators have the capability to create a custom permission level and define what a user can do within the boundaries you create for them. This can include creating a custom permission level where a user can edit documents, manage permissions, change site settings, etc.
For example, say you have an HR executive who should be able to view, edit, and delete employee records but shouldn’t be able to tamper with any site settings. You can create a custom permission level around this and name it “HR Executive – Employee Records Management.”
Best practice for custom permission levels
Based on our experience, we have a few suggestions before creating and assigning custom permission levels within your organization.
The following practices help avoid confusion and roadblocks for end-users:
- Thoroughly analyze user roles and responsibilities to understand what a user requires for seamless workflow and what they don’t, based on their job description.
- Consult with stakeholders to understand their point of view, what they require access to, and why.
- Document the purpose and scope of each permission level to keep things clear for everyone.
- Conduct periodic reviews to ensure permissions are consistent with organizational requirements and security policies.
Best practices for permissions inheritance and breaking permissions inheritance
Consistency of security policies directly influences how secure your Microsoft 365 environment actually is. If we specifically talk about the role of permissions management in ensuring consistency, here’s how permissions inheritance will help:
In SharePoint, permission inheritance means permissions assigned to a ‘parent object,’ like a site collection or site, are automatically passed down to the ‘child object’ created within that site collection or site.
The parent-child relationship with permissions means that the child object gets the same permissions as the parent object, reducing the manual effort required to constantly assign permissions whenever a new object, such as a site, is created.
The best practice for security within your SharePoint environment is to leverage permission inheritance to your advantage to create a structure where permissions are automatically assigned without repeating the same process of assigning new permissions.
Breaking permission inheritance
Instances will occur within your SharePoint environment when you’ll need to assign customized permissions to certain objects. In instances like this, you’ll be changing the default permissions which that object inherited from the parent object. This is called breaking permissions inheritance. This allows for more granular control over access and enables unique permissions for specific objects.
The best practice is only to break permission inheritance when absolutely necessary and document it so all customized permissions can be tracked. Also, when documented, make sure the reason for the discontinuity in default permissions is also explained.
But still, know that by breaking permission inheritance too much, you’ll create an overly complex permissions structure that will be difficult to manage. You might be able to understand the customized structure because you’re the one making these changes, but you’ll end up making lives difficult for new administrators who have to deal with this.
P.S. There’s an easier way to manage permissions, ensure consistency, and live inside a completely secure SharePoint environment. ShareGate’s permissions management feature is the ultimate solution.
Best practices for the principle of least privilege
One critical aspect of maximizing security within your organization is only allowing users necessary access to information. Needlessly giving permission to the intern to access a folder that contains the company’s finances isn’t smart, is it?
The principle of least privilege emphasizes just this. Here’s how:
What is it?
The principle of least privilege states that users should be given the lowest possible permissions required to fulfill their job responsibilities. This minimizes unnecessary risk and reduces security issues such as data leakage, data modification, or unauthorized access.
Importance and best practice in permissions management
The importance of implementing the principle of least privilege within your organization is paramount, as the risk of security breaches is minimized. Regularly review and adjust permissions based on this principle. This will help maintain a secure SharePoint environment and protect sensitive data from unauthorized access or misuse.
Best practices for simplifying SharePoint permissions management using groups
- Plan and organize: Before creating SharePoint groups, carefully analyze the user roles and responsibilities within your organization. Group users based on their common permissions requirements and responsibilities. This helps ensure that permissions are assigned efficiently and consistently across your document library.
- Limit unique permissions: Aim to minimize the number of unique permissions within your SharePoint environment. Too many unique permissions can lead to complexity, making it challenging to manage and troubleshoot permissions. Whenever possible, leverage inheritance and SharePoint groups to maintain a consistent and manageable permission structure.
Method #1: Using Microsoft
Add users to a group
- On the SharePoint site, click share/members.
- Click on Add Members.
- Enter the names or e-mail addresses of the users you want to add will appear in the dialogue box.
- You’ll also be able to set permissions levels when sending the invite.
- Once done, click on Share, and the invite will be sent.
Remove users from a group
- Go to the SharePoint site and click Settings.
- Click Site settings/Site Information.
- Click View all site settings/Site settings. (Some users might need to click on Site contents before viewing the Site settings dialogue).
- On the Site Settings page, go to Users and Permissions—> People and Groups.
- Go to People and Groups—>Quick Launch and select the user you want to remove.
- Click Actions—>Remove Users from Group.
- A confirmation dialogue box will pop up. Click Ok to proceed and remove the user.
Grant site access to a group
- Go to the SharePoint site and click Settings.
- Go to Site Permissions.
- Click Advanced Site Permissions once the site permissions page opens.
- On the Advanced Site Permissions page, click on the Permissions tab.
- Click Grant Permissions.
- Click on Share, and enter the group name to who you’d like to give access.
- After you click on Share, a prompt will appear asking you the level of permissions you want to give to the group. By default, the group will be able to edit. But, you can change permission levels by clicking on Show options—> Select a Permission Level/Select a group or permission level.
- Once permissions for the group are finalized, click Share to proceed.
Assign a new permission level to a group
- Go to the SharePoint Site and click Settings—>Site Settings/Site information on the SharePoint site. (Sometimes, you’ll have to click on Site contents and then Site settings).
- Once on the Site Settings page, click on Users and Permissions—> Site Permissions.
- Hover over the user/group to which you’d like to assign a new permission level. Tick the check box to select them.
- Go to the Permissions tab and click on Edit User Permissions.
- You’ll be prompted to a screen where you’ll be to grant custom permissions to the group. If you check more than one box, the user will get a combination of all those permission levels.
Method #2: Editing permission assignments using ShareGate
To grant permissions to users or groups in a target location, go to Explorer and select the sites where you want to apply the changes. Click + Add from the Permissions section in the Quick actions menu.
In Add permissions, you can select one or multiple users, and grant them new permissions over the items that were previously selected in the Explorer. You can either add them to existing SharePoint groups, assign them as Site Collection administrator, or assign them explicit permissions. These can be out-of-the-box permission levels or custom ones. You can also assign permissions to SharePoint groups and Active Directory groups.
Copy user permissions
One particularly interesting feature is the ability to copy the permissions of a user to another.
For example, your company makes two hires for the Sales Team: Alex and David. As an IT admin, you know Alex and David’s permissions should be the same. In ShareGate, copy Martin’s already existing permissions and assign them to Alex and David. That’s it! Alex and David now have the same access to site content as the rest of the team. You can select a tenant, sites, or any SharePoint object for this operation.
It’s been a few months, and Alex and David have been promoted to new positions with different job descriptions. As a result, the old permissions are no longer required.
Our Remove Permissions option is there to help you remove permissions from users or groups.
With Remove permissions, you can select your tenant, sites, or other SharePoint objects to:
- Remove from SharePoint group membership
- Remove from site collection administrators
- Remove their explicit permissions
- Remove all permissions
ShareGate’s Permissions Matrix Report: An answer to permission management problems in SharePoint
Permissions not only need to be managed but also audited regularly to maintain an ongoing standard of high-level security for your organization’s data.
ShareGate offers a built-in Permissions Matrix Report, which covers all those bases. Think of it as your all-knowing personal security assistant.
With one click, you get comprehensive visibility of what users and groups have access to and their permission levels, in your SharePoint and Microsoft 365 environments.
With the results from our Permissions Matrix Report, you can:
- See who (and which groups) can access what, including external users and the content shared via anonymous links.
- Plan your migration by helping you answer the question “Are these the permissions I want to have when I migrate to the destination?”.
- Compare pre- and post-migration. Get a snapshot of your permissions before you make the move. When your migration is completed, you can compare your source to your destination.
If you can’t wait to dive into our Permissions Matrix Report and all our Microsoft 365 management solutions, start a 15-day trial with ShareGate (it’s free!).
It’s safe to say that there’s a fair amount of attention spent on permissions management in SharePoint. The platform is evolving to cater to digital and secure collaboration.
Advanced permissions capabilities allow you to track who has access to what across the organization. And if you want more flexibility in staying updated about these permissions, you always have ShareGate’s Permission Matrix Report to rely on.