I have created a new SharePoint Modern Team site and i got 3 security groups created for us, as follow:-

enter image description here

but the problem i am facing is that the "Site members" will have Edit permission, while i want them to have "Contribute". and modifying this from the UI will not be possible, as the "Edit User Permission" will be disabled, as follow:-

enter image description here

now i read many links about this problem, and seems we can modify the Edit permission level using power shell, but lot of folks mentioned that this is not recommended..

Also recently i came across this link Changing Default Permissions in Office 365 Group Sites and the author mentioned that we can overcome this problem by adding a new security group inside sharepoint and grant it Contribute permission. But if i create a new sharepoint security group and i grant it a contribute permission (while i leave the built-in "Site Members" which have Edit permission level empty), then i will loose the benefits of having a real SP modern team site? is this correct?

I mean sharepoint modern team sites, assume that the built-in "Site Members" contain users, so they can use the shared calendar,shared mailbox, planner ,etc.. but having users added to the sharepoint modern team site using a sharepoint group (rather than relying on the office 365 built-in "Site Members" ) will minimize the benefits of having a real Office 365 modern team site, as users added to the custom sharepoint group (which have contribute permission) will not be able to use the Office 365 Group's features mainly; shared calendar, planner, mail box, etc.. is my point valid? and maybe it will be better to have a communication site instead of having SP modern team site in this case? so can anyone advice on how we can change the default Permission in sharepoint modern team site for the Members groups, from Edit to Contribute?

3 Answers 3


The blog you linked to has the correct answer. It's not optimal, but it works.

One source of confusion is that after creating a team site, there are two groups with the same name. For example, if you create a new team site named "project 1", the following groups will be created:

  • "project 1" - This group is visible in the list of groups in the admin console. The admin console will show that this group has an email address, and a group type of Office 365. The admin console will also show the list of owners and members. When viewing the home page of the site, it will display "x members" at the upper right. clicking on it will display the members of this group.
  • "project 1 members" - This group is visible by navigating to site permissions --> advanced. This page will show this group (plus others), and it will have a group type of "SharePoint Group". This group will have a default permission level of edit
  • "project 1 owners" - same as above, with a permission level of full control
  • "project 1 visitors" - same as above, with a permission level of read

If you click into the project 1 members SharePoint Group, you will see that it has one member by default: "project 1 Members", which is the members of the Office 365 Group.

If you go back to the homepage and to site permissions, you will see listings for site owners, members, and visitors. These are references to the SharePoint groups. The site members group will show one member, "project 1 Members members". Changing the dropdown from edit to read does not change the permissions of the SharePoint group, but instead moves the Office 365 Group out of the project 1 members sharepoint group, and into the project 1 visitors sharepoint group.

Given the above:

  • navigate to the advanced permissions screen, and click on the project 1 members SharePoint group
  • click the checkbox next to the project 1 members office 365 group
  • click actions --> remove users from group
  • Go back to the advanced permissions screen, create a new SharePoint group, and give it contribute permissions. After creating the group, it should take you to the people and groups page, showing the membership of your new group. click "new", and add the project 1 members group to your new group. (this will be the office 365 group.)

Once you've done the above:

  • The members of the project 1 office 365 group will have contribute access.
  • Clicking the x members link on the homepage and modifying the group membership will work fine, as that still modifies the membership of the office 365 group, which has contribute access.
  • clicking "site permissions" will still show project 1 owners with full control, but will not show anyone as a member or visitor. This is the flaw with this approach. The group has contribute access, but this screen will not display it. Instead, this panel will simply state "there are additional groups with permissions on this site"

(In my procedure, I removed the O365 Group from the SharePoint Group. In the blog post you linked to, Paul suggests to switch it to a visitor. I'm not sure which I like better. Paul's approach still makes the group visible on the site permissions panel, but that also makes it really easy for a user to switch them back to a member, defeating the purpose of all of this).

So, not a perfect solution, as the site permissions panel doesn't allow you to view or change the permissions for members, and any further changes will need to be done in the advanced site permissions screen. This does, however, preserve the ability to modify the list of site members via the "group membership" panel from the home page.

edit: I mentioned the other post wasn't "optimal". This was not a criticism of the blog post, rather that I wish MS provided a way for us to do with without all of the above.

  • i tried your appraoch and it worked well. i thought if i follow the blog or your appraoch, i will end up adding users to the sharepoint site only, without adding the users to office 365. but following your appraoch & the blog, when i click on "x members" at the upper right, and i add a user then the user will be a member of the office 365 group, so the user can benefit from the shared calendar, planner etc + the user will only have contribute permission on the sharepoint site.
    – John John
    Commented Nov 29, 2018 at 0:33
  • so now the final question, do you think there is any harm if we are going to grant office 365 users contribute on the sharepoint site instead of edit.. i would say nothing should be wrong?? second question. now i have heard many developers mentioning that they are not going to use SP modern team sites, because members of the team site will get Edit permission on the SP site,, but with your workaround,, this can not be considered as a real problem?? is this correct?
    – John John
    Commented Nov 29, 2018 at 0:35
  • 1
    There's no harm that i know of: this shouldn't affect users' abilities to interact with other O365 group services. Re not using team sites because of this issue, this workaround certainly seems to address it. However, the site owner still has very easy ways to give people edit access. If we lock down the owners, then perhaps group membership should be handled dynamically via azure ad, which then might make this whole issue moot anyway.
    – Mike2500
    Commented Nov 29, 2018 at 1:08
  • now in our case, i only allow owners to be one of our sharepoint admins, who are already aware that they should not add users to the SP site with Edit permissions. so apart from site owners & global admins who else can add members to the SP modern team site and grant them Edit permissions? i do not think any one can do so?
    – John John
    Commented Nov 29, 2018 at 1:13
  • 1
    You're correct, that should be it, re giving edit access. Users with contribute won't be able to share out the site with others, especially not with an even higher level of access.
    – Mike2500
    Commented Nov 29, 2018 at 13:03

When you create a modern team site, it automatically creates an office 365 group (azure ad group) that contains all members and adds to site members sharepoint group. When you add user/invite user from modern UI you are essentially adding the user to the Azure Ad group. The services connected to the Office 365 group like shared mailbox, planner etc use the same azure group to manage permissions on the respective services. In this way if a user is added to the group, the permissions on all connected services are updated.

When you create a new SharePoint group and add users directly, those users only get access to the SharePoint site and they wont be able to leverage any other connected services as they are not part of the Azure group.

You can create SharePoint group and add the azure group to it and then assign contribute permission to the SharePoint group just like as mentioned in the link in your question and other answer (to ensure users are managed by azure ad group), I would not personally recommend it.

One issue I have know is that if the group is connected to MS team, and then user tries to add a wiki tab for the first time they will encounter an error due to the fact that they just have contribute permission on the corresponding SharePoint site. The first time you add a wiki tab, it tries to provision a list and library (team wiki data) which requires the user to have 'add list' permission part of 'Edit' permission level.

As MS continuously updates the services, you never know what kind of cross service dependency they may add and thus breaking your changes.

If you do not need services provided by modern group site, I personally would recommend to create a classic team site and enable modern experience on library level (if tenant level is set to use classic). This way you are free to manage permissions in manner you wish. You also have an option to connect to an office 365 group in case your requirements change in future.

  • the main issue is that Microsoft is pushing/recommending toward using modern site templates, and seems most of the investments will be done on these modern templates, compared to classic sites. i have been using classic sites with modern UI on many projects.. but now we are starting to build a new intranet for one of our customers, and they want to have a long investment, so they asked us to utilize the latest technologies offered.. now MS modern team sites are great, also if we compare them to classic team sites, then modern team sites have more modern web parts (twitter, jira, etc) +
    – John John
    Commented Nov 29, 2018 at 11:08
  • they contain features from office 365 groups.... now i know that the workaround offered in the first answer and in the link i provide, might cause issues.. but i think those issues are related to the fact that Members can not add lists and libraries since they are contributors and not editors.. so i think it is fine.. now if Microsoft want to add some features or updates to the SP modern team sites, they will not be affected if the members are contributors or editors..
    – John John
    Commented Nov 29, 2018 at 11:09
  • so there might be issues , but they are not critical, and i do not find my self eliminating using MS modern team sites for this reason. what do you think?
    – John John
    Commented Nov 29, 2018 at 11:09
  • If modern experience is already turned on in SharePoint admin center and your requirement does not include using any connected service, then team site classic is still an option (you still get modern experience without additional connected service). You always have an option to connect those team sites to an group in future and convert to modern team site ( docs.microsoft.com/en-us/sharepoint/dev/transform/… ).
    – sssreddy
    Commented Nov 29, 2018 at 14:27
  • But if you are ok with one of issues you might encounter in future, then you can go with instructions suggested in your link. Make sure users are added to the Azure group and not directly to the site to ensure they can at least access the connected services.
    – sssreddy
    Commented Nov 29, 2018 at 14:28

The permission level of the groups can be changed using the PnP PowerShell module:

Connect-PnpOnline https://tenant.sharepoint.com/teams/myteam
Set-PnPGroupPermissions -Identity "myteam Members" -AddRole "Contribute" -RemoveRole "Edit"

Yes, it is not recommended, that's why there is no option to change the permission level to Contribute in the UI.

I do not think the solution in the blog is recommended either.

Both methods achieve the same outcome of removing the Manage Lists permission and either could break functionality or provide unintended results.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.