Best Practices for Permissions on an O365 Group SharePoint Site

Brent Ellis
Valued Contributor

So it seems that you can break permissions of individual lists/libraries/items, but you can't actually set permissions on the site as a whole?  Am I missing something when looking at configuring general permissions of a SharePoint Site


Is there general guidance on best practices for doing complex permissions on an O365 Group SharePoint Site?

37 Replies

I think that Site Permissions are determined by the Group membership/ownership.

I agree with Salvatore...behind the scenes a Site Group has the regular SharePoint Groups: Owners, Members and Contributors. By default, the Group itself is added to the Site Members Group...you can check this typing directly in the browser the people page: _layouts/15/people.aspx

Juan, do you know, BTW, why the Group itself is added to the Site Members?

@Brent Ellis

Anyway, if you feel adventurous, you can try "https://<tenant>.sharepoint.com/sites/<group>/_layouts/15/user.aspx".

Be careful! :smileywink:

Of course,
You can always use "Old" URLs :-) directly in the browser

Nobody has really answered the question here, and I too have similar questions in terms of best practice.  For instance, what if you want to open your Group site up to a wider audience without adding group members?

at the moment I'm leaning towards not touching groups team sites permissions. My main concern is user experience. Even though you could assign permission to nonmember of this group, the end user would not see the group in the left navigation compared to when he/she is a direct member in that group.  

Also I've seen a new Site Permissions UI (right side pane) coming up, amd rumors about a view only permission set. 

Hi all,


Is it correct that when creating a group the default permissions for members is "Edit" and not "Contribute" correct?


Is it possible to change(e.g. to contribute) this when provisioning? Is it wrong to think that the default permissions for members is a bit much? I mean they have the potential to mess up things just because they can.



That is accurate. And I whole-heartedly agree with bumping it down to contribute. We do that manually right now.

You can access the traditional SP permissions page including the Visitors group using this URL. That would be a way to make the group visible to additional people who aren't necessarily members of the group.



Hi @Brent Ellis, When you say manually do you mean you set the default when you provision the Group e.g. via powershell? Would love to know :)

Nah, straight up manually, navigate to user.aspx and click change permission

It is ironic though, with all the user interface changes "taking away" capabilities from site admins, why not load down the regular members with more than they need
Thanks! Good to know I can change it even manually :/ hope they address this in the future.
So......I can now no longer change the default Group membership permissions

It appears that Group Members, Group Owners, and Group Visitors is totally locked down, and can't modify permissions at all.

Guess it was just a matter of time....neutering the sharepoint sites continues
I'm with you in this perception....also trying to look for workarounds seems not be the right thing to do. But I'm still missing what are the plans of Microsoft in regards of what can be done and can't be done when defining the security to access to a modern team site or a Group site

Also discovered the same...might be the fact that that default permission of "edit" for members may tie in closley with the other services so changing it might cause implications.


I hope they address this soon as it will become difficult to manage. 


Another question, is it possible to turn external sharing on or off for individual site collections which were created as part of a group? Since the collection does not appear in the SP admin site collections possible via Powershell maybe?





@Damien Flood wrote:

Another question, is it possible to turn external sharing on or off for individual site collections which were created as part of a group? Since the collection does not appear in the SP admin site collections possible via Powershell maybe?

Yes, it is.

See "Manage external sharing for Office 365 Group site collections" in https://support.office.com/en-us/article/Manage-external-sharing-for-your-SharePoint-Online-environm...

Damian, check this thread out of you haven't already. Good explanation of roadmap and contribute permissions in Groups. Pls they just have ability to change group membership a different way. And groups now included in PowerShell to get sites


Hi Brent,


in regards to the improved permission management for Office 365 groups (https://techcommunity.microsoft.com/t5/SharePoint/UPDATE-Create-Office-365-Groups-with-team-sites-fr...) there are some more options to handle advanced permissions - I wouldn't call this complex. However, this already helps a lot for several user scenarios.


Moreover, I'd recommend as best practices first to set each new Group as private so that not everybody in the tenant can access it. Second, only certain users in the regarding security group should be allowed to create groups. And third, consider the invitation to external users (guests): permit this generally or only allow for certain groups.


Unfortunately, at the moment this has to be done manually after a group's creation. This also applies to more granular permissions, which are still possible to modify in the SharePoint site. However, I'd wish to have a better permission management or other governance options during groups creation process in order to enforce policies. At the moment this is only possible with 3rd party solutions. For now I can just say, use PowerShell and the manual permission management in the SharePoint sites to achieve your complex group permissions.


Hope this helps.


Can somebody please shed some light here -


When an Office 365 group is created, the Owners group in the Sharepoint team site has no user added to it !

Now, when we reduce the permissions of the Members group to contribute, there is no user in the site, who can then manage the permissions on the site !!

Its strange, why isn't the user who created the Office 365 group added as an Owner in the site. Or am I missing something here ?

Hi @Vipul Kelkar,


I guess, this is a GUI issue, because I have the same problem. I cannot see the users in the regarding groups. However, when I check the permissions, I can see that regarding users should have permission due to the membership of regarding permission group.



Microsoft would say, this is by Design, although it's actually a GUI bug. ;-) Hope, this will be fixed.

In the current Groups UI, site permissions are managed in the new pane accessible from the cog menu:


2017-03-07 15_11_51-TestPrivateGroup01 - Home.jpg

And, as clearly stated, owners and members should be managed only by OWA.

Hi @Salvatore Biscari,


you are right, it's recommended to manage permissions with the end user interface. However, every PowerUser is aware how to use the native permissions from previous normal site collections. Very often companies have complex permission requirements, which will definitely not be covered by only three groups (Owners, Members, Visitiors). Therefore we want to conifgure additional permissions directly on the site. It's deifnitely confusing, when users are granted permission to this site, but there is actually nobody in the regarding groups.


Doesn't matter, which UI I use, it should be deifnitely consistent to avoid ambiguities. That's my opinion. Happy to hear your opinion. :-)

I agree with you: the various UIs should be consistent.

Nevertheless, Groups have definitely a non-standard implementation wrt their parts (team sites, shared mailbox etc.): I think we should accept it.

Also, in classic team sites, upon creation, the three groups (Owners, in particular, but also Members and Visitors, of course) are empty.

You think that's fun, try creating a subsite in a Group team site, the permissions there are all wonky too. The same restrictions are applied to "sub-site Members" (can't edit default "Edit" permissions). It tries to act like a "Group", but its not, "site information" doesn't load because it is not a Group. No way to get back up a level unless you hard code in a "go back" link or inherit menu, which may or may not work depending on the day.

This is a mess.
Ah ! well thanks for that. So the user IS an owner in the site.
I am not sure why but I don't see the note "To view or change the group members..." as you have indicated in your screenshot. But that apart, the outlook interface will only allow us to add members to the group which are directly added to the AD group.

Now that we have a full team site, people are going to want to manage permissions directly in team site on the list, libraries etc or for that matter provide access to the users to only READ the content. I was trying something similar and was baffled to see the owners group empty.
  1. For managing permissions, you can use (with care!) the hidden page https://tenant.sharepoint.com/sites/group/_layouts/15/user.aspx. But, while there, leave alone the standard groups!
  2. In the "Site permissions" pane, under the cog menu in the connected team site, you can safely change the default permissions for the standard groups.
  3. In the OWA UI, you can safely manage the standard groups membership: add members, remove members, promote members to owners, demote owners to members etc. The same can be done in the "Group membership" pane in the connected team site. And the same can be done also by PowerShell.




Hello everyone! 

I absolutely agree with Robert Mulsow. I also cannot see members once I enter the advanced site permissions options for a specific private group. 


Also, it is very difficult to set permissions on a folder level. I entered the library settings and then entered permissions for this library. Later I tried to break the inheritance, but I ended up being kicked out of the group. 

Any recommendations?


It is important to be able to set permissions on a document or a folder level as 3 types of group members (owner, member, visitor) will not cut it :(.


As it has been stated in several other threads, it is better to leave alone permissions in Groups teamsites.

If you need more sophisticated permissions structures, then you should better use classic team sites.

Or a modern communication site, if the design template fits the use case.

Great blog about these modern sites, Groups, Teams, etc. and what's the recommended way to use them - also from security perspective.



I found this helpful:
When working with Team sites (that have an associated Office 365 Group), there are some options to grant site access.

Start by selecting the gear icon in the upper right hand corner and select Site Permissions from the drop down menu
Select Invite People:
Add Members to Group: this option not only grants access to the site but adds the account to the Office 365 group. When an account is added via this method, the number of members at the top right of the page is updated. Note, that when using this selection only Owner and Memberpermission settings can be granted. Read access cannot be granted utilizing this method.
Share Site Only: this option adds the user to the appropriate site group. This does NOT add them to the Office 365 group. When added using this selection, the account can be granted Owner, Full Control, Edit or Read access. However, this does not update the members number on the home page of the screen and does not allow the account to participate in conversations (in a private group). This is the equivalent to selecting Advanced permission settings and adding the account that way.
Bottom line: Even though the Advanced permission settings can be utilized to grant permission to ‘Modern’ team sites, but isn’t necessary. Don’t be afraid of the Invite People selection. Just be aware that the Add Members to Group will add the user account to the Office 365 Group and can only be used to gran Owner or Member permissions. Share Site Only will grant access to the team site only and will add the account to the appropriate site group (and this is the only option for read access).

Yeah, it’s important to differentiate between office 365 group membership and good ol sharepoint permissions :)

@Brent Ellis wrote:
That is accurate. And I whole-heartedly agree with bumping it down to contribute. We do that manually right now.

We do the same.

Related Conversations