Understanding permission groups in Teams and SharePoint

Understanding permission groups in Teams and SharePoint

One of the most confusing aspects of Teams and SharePoint in Microsoft 365 is the relationship between permission groups used to control access to both of these resources. This is especially the case as every Team in MS Teams has an associated SharePoint site (the ‘Files’ tab).

This post explains how permission groups work between MS Teams, Microsoft 365 Groups and SharePoint.

SharePoint permission groups

Before discussing how Teams permissions relate to SharePoint, here is a brief reminder of how SharePoint permissions work.

SharePoint has always had three default permission groups, prefixed by the URL name of the site, as shown in the screenshot below (the name of the site always prefixes the words Owners, Members and Visitors).

Site Owners

  • People (including in a Group, see below) added to the Owners permission group have full access (full control) to all parts of the site and are usually responsible for managing the SharePoint site. There would normally be two or three site owners.

Site Members

  • People (including in a Group, see below) added to the Members permission group have add/edit (contribute) rights.

Site Visitors

  • People added to the Visitors permission group have read-only (view) rights.

These permissions are set at the site level and inherited on everything in the site, unless that inheritance is broken and unique permission are applied. Additional permission groups can be created as necessary but most SharePoint sites only use the default Owners, Members and Visitors groups.

Microsoft 365 Groups

Microsoft 365 Groups were introduced in 2017 and control access to resources, like Security Groups.

However, unlike Security Groups, which usually provide access to individual resources (such as a single SharePoint site, or Line of Business (LOB) system), Microsoft 365 Groups control access to multiple linked Microsoft 365 resources.

Microsoft 365 groups, distribution lists, mail-enabled security groups, and security groups (collectively referred to as Active Directory (AD) groups, are all created in ‘Groups’ area of the Microsoft 365 Admin portal.

When a new group is created, the following options appear.

As noted above, Microsoft 365 groups are recommended. It is important to understand the relationship between Microsoft 365 groups, Teams and SharePoint.

A new group has a visible mailbox and a Team is created by default

When a new Microsoft 365 group is created (from the dialogue above), it creates:

  • At least one Owner must be specified. The Owner/s are responsible for managing the Members group.
  • An Exchange mailbox with the same email @ name as the Microsoft 365 group. The mailbox is visible in Outlook to the members of the Group.
  • A SharePoint site with the same URL name as the Microsoft 365 group.
  • By default (unless the checkbox is unchecked), a new Team is also created in MS Teams.

When a new Team is created from MS Teams, or a new SharePoint Team site is created, it creates:

  • A Microsoft 365 Group with an Exchange mailbox and a SharePoint site (‘Files’ tab).
  • The name of the Team becomes the name of the Group and the SharePoint site.
  • The mailbox is not visible in Outlook and is only used for calendaring and for the storage of Teams chats (in a hidden folder).

Importantly, when a new Microsoft 365 group or Team is created (which creates a Microsoft 365 group), the Group Owners: (a) are the same as the Team Owners and (b) are added to the SharePoint Owners permission group, as explained below. .

Group/Team Owners and Members

In other words, the Microsoft 365 group owners (group) is added to the SharePoint site owners permission group – a ‘group within a group’.

That is, the Microsoft 365 group controls access to the Team and the SharePoint site as shown in the diagram below. Security Groups may also be added to the Microsoft 365 Group site, but this does not provide access to the Team.

The relationship between Microsoft 365 Groups, Teams and SharePoint

This ‘group within a group’ model is visible from the ‘Site Permissions’ section of the gear/cog icon as shown below (the name of the Microsoft 365 Group/Team/SharePoint site is ‘SharePoint Admin’). The SharePoint Admin Group Owners (group) is in the SharePoint site owners group, and the SharePoint Admin Group Members (group) is in the Site members group.

If a mouse hovers over the Group ‘icon’ (in the above example, GO or GM), it is possible to view the members of the Group and, for Owners, to modify that list. Confusingly, the ‘GM’ in the SharePoint site permissions group becomes ‘SG’ in the drop down list.

You can also see the ‘group within group’ model from the back-end ‘Advanced permissions’ section of the SharePoint site, but you cannot manage the Microsoft 365 Group members here.

Implementing the model

As with Security Groups, the members of Microsoft 365 Groups will usually be a logical group of people who require access to something, in this case access to the SharePoint site or the Team (for chat, files, or other resources).

The main thing to remember is that membership of the (backend) Microsoft 365 Group provides access to BOTH the Team and the Team’s SharePoint site (the ‘Files’ tab in a Team).

  • Every Team in MS Teams will usually consist of the members of a logical group with a common interest – a business unit, project team, or with some other work relationship, for example, the members of a committee. The Team Owners are responsible for managing the Team Members.
  • The Team Owners are the SharePoint site owners and are responsible for managing the site if they decide to access it directly. The Team Members are the SharePoint site members and have the ability to add or edit content, usually via the ‘Files’ tab in Teams.

Note: Security Groups with the same members as Microsoft 365 Groups (and Teams) may already exist. There is no need to add a Security Group if it has the same members as a Microsoft 365 Group.

As noted earlier, a Group/Team does not have visitors with read-only rights. Every Member of the Team has add/edit access to both the Team and its associated SharePoint site.

  • If there is a requirement to give specific other people either add/edit or read-only access to the SharePoint site, that outcome is achieved by adding people by name, or a Security Group, to either the SharePoint Members or Visitors group.
  • If there is a requirement to give everyone in the organisation either add/edit rights, or read only access, to the SharePoint site, that outcome is achieved by adding ‘Everyone except external users’ to either the SharePoint Members or Visitors group.

External guests may also be added to the Team and the Team’s SharePoint site.


7 thoughts on “Understanding permission groups in Teams and SharePoint

  1. I currently run a legacy SharePoint site where the permissions have been edited so Members don’t have delete privilege. I’d like to transition to a modern site without giving Members back the ability to delete. I understand I can edit permissions in a modern site through Advanced Permissions Settings, but this takes me into the old classic interface, and I wonder if that is going to go away eventually. Is there a chance that MS would leave me high and dry by sweeping away the controls accessed through the old interface?

    1. Good question, I am also wondering when Microsoft will ‘modernise’ the Advanced Permissions interface. My best guess is that it will eventually have a new look and feel but the settings will still be available to remove the Delete option from the Edit and Contribute levels. I assume you know you can get to these via the URL link – /_layouts/15/editrole.aspx?role=Contribute for example, added to the end of the site name will take you directly to those settings. (If you’re not already familiar with these, it’s a good idea to keep a list as they can be very useful).

  2. Thank you for explaining this in detail. I have an scenario that I would like to run by you.
    Imagine that I have Team called “Corporate Sales”. Within this Team, I have many SharePoint Lists used for various purposes. One of the List is called “Customers”.

    Now, I imagine that I have another Team called “Construction” where team members discuss issues about construction issues. What I would like to do is to give the “Construction” Team access to see the “Customers” list in the “Corporate Sales”.

    What would l need to do? – My guess below:
    1) Open the “Corporate Sales” Site Permissions via SharePoint
    2) Add a New Sharepoint Group and call it “Construction Team Members”
    3) Add the MS365 Group “Construction” into that Sharepoint Group
    4) Update the “Customer” List Permission and include the “Construction Team Members” as Reader.
    5) Add a new Tab in the “Construction” Team and link it to the “Customers” SharePoint List.

    Would that work?

    1. Thanks for the feedback Jose.

      Just to be clear, I will assume that the Corporate Sales and Construction teams both are using Teams rather than SharePoint via the browser.

      You can give direct access to a M365 Group in a library or list. So I would suggest, if you only want to give access to a list, modify the permissions only on the list.

      So, if you only need to give access to the list, go to the Corporate Sales site, open the list, click the ‘gear’ icon then ‘List Settings’, then ‘Permissions for this list’. This will open the ‘classic’ view of the permissions. Click on ‘Stop inheriting permissions’ at the top left, then click on ‘Grant Permissions’, add the M365 Group/Team members name, and remember to tick ‘Show options’ to set their access rights and disable the email notification option. Then click Share. You should then see the Group name with the permissions in the list permissions.

      Now go back to the list, copy the URL for the list, and create a tab for the Construction team and paste the link there.

      1. Hi Andrew, yes, both departments are using Teams. I assume that the “Construction Teams” members can’t access any of the Posts, or Files from the Corporate Sales Teams, correct? I thought that before I can grant the “Construction Teams” access to the Sharepoint List, they needed to be a member of the site in the first place. In other words, you can’t access a List from a Sharepoint Site unless you have access to the site itself first. Maybe I am mistaken. I will try it out tomorrow. Thank you.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s