UPDATE: Create Office 365 Groups with team sites from SharePoint home moving beyond First Release


We recently completed the worldwide rollout for Office 365 Groups getting full-powered SharePoint team sites at the end of January 2017.  Our next step is to now bring the ability to create SharePoint team sites connected to Office 365 Groups from SharePoint home beyond First Release. This next phase of rollout will begin today, and is expected to reach all customers worldwide over the next month. We also wanted to share some of the additional capabilities we’ve added to group-connected team sites since we first began roll out to First Release.

Create Office 365 Group-connected team sites from SharePoint homeCreate Office 365 Group-connected team sites from SharePoint home

No matter where you create an Office 365 Group from – whether SharePoint, Outlook, Microsoft Teams, Yammer, or elsewhere – you consistently get the full collaborative power of a connected SharePoint Online team site among the other services groups provides (shared inbox, shared calendar, Planner plan, team notebook, and more).


This move beyond First Release includes the capabilities described in our November blog post:

  • Fast creation of sites connected to Office 365 Groups from the SharePoint home page
  • Editable team site home pages that look great at your desk and on your phone
  • Modern creation panels for new libraries and lists
  • In-place navigation editing
  • Site settings panels for editing site information and site permissions
  • Modern page creation in classic sites
  • Admin controls for team site creation

The site permissions panel listed above has been enhanced to include options for adding members to the site’s Office 365 Group or simply sharing only the team site without providing access to other group resources.


The panel is intended to provide simple permissions management, but also includes a link to ‘Advanced permission settings’ for site owners that have a need to do things like add custom SharePoint permissions & mappings.

Site permissions management panelSite permissions management panel


Note this panel also allows you to add users or groups to the ‘Site Visitors’ permissions group, so it is easy to provide read-only access to the site.  All you need to do is add a new person or group via the ‘Invite people’ button, and then change their permission level to ‘Read’.  The user or group’s permission level determines which permission group they appear under – those with ‘Read’ permission will appear in the ‘Site Visitors’ category.


Changing permission levels directly in panelChanging permission levels directly in panel


Managing group-connected team sites

Since new team sites are connected to Office 365 Groups, managing them involves possible interactions with Office 365 Group settings in addition to those provided by SharePoint.  Examples include settings that apply to groups such as whether group creation is allowed in the tenant, which users are permitted to create groups, usage guidelines URL or group classification labels. Once the group-connected site is created, management of the site is likewise split between Azure Active Directory (AAD) PowerShell cmdlets and the SharePoint Online Management Shell.  Anything dealing with creation, deletion, un-delete (restore) or membership happens through AAD.  SharePoint-specific management, such as storage quota and link sharing policies, take place using the SharePoint management tools.


For governing modern site creation, this support page details the administrative controls, but is useful to summarize the relationship between a group’s policy settings and how the SharePoint ‘Create site’ experience behaves.  By default, if group creation is enabled in the tenant, the ‘Create site’ command will appear on SharePoint home, and if a user is permitted to create groups they will get the site creation experience.  If the user is *not* permitted to create groups, they will get the classic self service provisioning experience that results in the creation of a subsite.  The table below describes how the combination of group and site creation settings work together:


  * The current user is considered to have group creation permissions if the AAD property EnableGroupCreation is true, or it is false but the user is a member of the security group assigned to the GroupCreationAllowedId AAD property.   

** Site creation is enabled via SharePoint Admin Center under Site creation settings:

Site creation settings in SharePoint Admin CenterSite creation settings in SharePoint Admin Center 

In addition to managing site creation, we are also enabling the SharePoint Online PowerShell cmdlets to administer modern, group-connected site collections.  This means that modern team site collections can now be enumerated with the Get-SPOSite cmdlet with the following example:


              Get-SPOSite -Template GROUP#0 -IncludePersonalSite:$false


Most parameters for these site collections can also be set using the Set-SPOSite cmdlet, with the exception of those that would result in breaking connection with their corresponding Office 365 Group (e.g. you cannot set the Owner property using this cmdlet – you would need to set the Group’s owners via AAD).  Please refer to the respective documentation for each of the above cmdlets for additional details.  For more information on using PowerShell to manage Office 365 Groups, this article may be helpful as well.


What else is new?

In addition to the above, this phase of the rollout includes a couple of previously unannounced capabilities.


The first is a group membership management experience that lives in SharePoint itself.  Now, when you click on the member count of the group in the site header, you will be presented with a new group membership panel that allows you to add members and change their roles between owners and members, or remove them outright.  Users will no longer need to jump to Outlook to manage the group’s membership.

Group membership management panelGroup membership management panel 


The second is Content Type Hub syndication – modern sites can now consume content types that have been published from a central content type hub.  We heard feedback that this is an important feature to enable, and we are including it in this rollout.


As noted above, this rollout will take place over the course of a few weeks.  We are very excited for you to take advantage of modern, connected team sites and look forward to any feedback or questions you may have.  As always, please ask in a reply to this thread. 



76 Replies

What impact does setting the Group Members to Read on the sharepoint site have on Group Files, Notebook, etc (like from the Groups UI, and Groups mobile app?)


I assume any of the Group workloads that technically live in SharePoint would just become read-only?


Also, is there the possibility to do any kind of different permission levels for standard Group roles

- Like make Group Members Contributors instead of Editors

- Make Group Owners Editors, not Full Control

- etc?

Great to see and try out Group Membership today. Impressive rate of innovation here, well done.

Hi Brent, great questions.  You are right to note that if the group members are dropped to 'Read' on the SharePoint site, then any resource in SharePoint will be read only, including the Notebook. 


On the questions around more advanced permissions, the goal of the new permission panel is to simplify and streamline the most common permission actions.  The panel shows the three default SP groups created for every site.  For those looking to implement more complex permission configurations, the panel provides an affordance to go to 'Advanced permission settings' which takes you to the classic user.aspx permissions management experience. 


We are also looking at expanding the simple UX to expose a 'Site Contributors' group which would assign 'Contribute' to people or groups put in that bucket.  We have it on our backlog, but would love to hear more from the community on how valuable it would be.  We've heard feedback that the contributor role is preferable in some cases where site owners want to limit members from modifying lists and their views. 


We do not have plans to allow for group owners to become editors.  Would love to hear more about that particular scenario as owners would lose the ability to manage permissions on the site, among other things, if they were dropped from full control to edit permissions.

BTW, there is a way to achieve the shift of members to 'Contribute' from 'Edit'. 

1) Create a new SP group, e.g. "Foo group Contributors" and assign it 'Contribute' permission level

2) Grant permission to this new SP group

3) Add the 'Foo group' member claim to this SP group

4) Delete the 'Foo group' member claim from the 'Foo members' SP group


Net effect is to give contribute permissions to group members, however the simple UX will only show the 3 default SP groups.  Per my previous post, we're looking at adding a contribute bucket in the panel to simplify.


@Tejas Mehta Any impact on Microsoft Teams by giving people 'Read' permissions in this manner? I'm assuming anything based in SharePoint will switch accordingly (files, onenote, etc), but is there any impact to the chat based conversation or anything else?

Hi David - the 'Read' permission applies to anything stored in SharePoint, which would include files stored by Teams.  Group owners should think about the implications of making SP read only for group members as it will have an impact on experiences outside of SharePoint that rely on things like file storage in doclibs, etc.

The bucket for Contribute will be great! My recommendation would actually be to make Contribute be the default. I think you'd find a lot of support for that in this community (both the bucket and the default)

Wohoooo! Content Type Syndication! This is big, as it is a major hassle to do this manually.

Scenario: usage of third party addons like harmon.ie that store .msg with metadata in SharePoint libraries requires the use of a custom email content type. 

I'm still hoping that Microsoft eventually implements this on their own, or at least enable drag n drop to Group Inboxes.

+1 to Brent's suggestion: make Contribute the default bucket

Are there any plans to surface these sites via the SharePoint Admin portal as manipulating via Powershell is all well and good but not a simple task ?


We currenlty have the situation where users have created groups but I am unable to tell who the owners are, this has potential to cause a nightmare around managment of content when the owners leave. 



I agree. There is a strong case for surfacing admin tasks more easily through the UI. PowerShell is an impractical option for most site and security administrators and particularly so 'at scale' Great functionality will not be implemented. @Tejas Mehta @Chris McNulty @Mark Kashman
Also :) +1 to Brent's suggestion: make Contribute the default bucket

Have you seen that http://www.modernworkplacesolutions.rocks/sharepoint-pnp-partner-story-how-we-use-the-pnp-in-the-sol... ?


I really like what they have done for «pending site deletion» and «orphaned sites»


+1 for Brent's suggestion to make Contribute the default!!!
Hi Tejas,

I'm trying to do step 4 in your post but not having much success in deleting the 'Foo' group from the 'Foo Members' SP group. In 'Site Settings - People and Groups - Foo Members' UI, the 'Foo' group can't be selected like any other group member as the checkbox is grayed out. I've also tried creating a new 'TestGroup' and adding 'Foo' as member with the same issue - checkbox grayed out preventing member from being deleted. From the Sharepoint mgmt shell I've tried the following command:

Remove-SPOUser -LoginName foo@company.com -Site https://<orgid>.sharepoi
nt.com/sites/<foo> -Group "TestGroup"

For LoginName, I've also tried the Foo group GUID given by:
Get-SPOUser -Site https://<orgid>.sharepoint.com/sites/<foo>

They both return the error "Remove-SPOUser : The user does not exist or is not unique."

Could you please point me in the right direction to delete the group from group membership?

Hi Proliance - there is a pending fix to the problem you're seeing where the remove action is greyed out for the member claim.  Until that fix shows up in your environment, there is a workaround.  From the modern permission panel, simply move the group members from Edit to Read.  Then, make sure that the member claim is added to the new SP group you created with the 'Contribute' permissions. 


Net effect will be what you desire.  You will see members have 'read' permissions in the modern panel, but under the covers they actually have 'Contribute' from the addition to the new SP group.

Hi Nicholas, we're working on surfacing group site collections so that they can be managed in UX (vs PowerShell).  We'll share more details when we can, but we wanted to make sure that PowerShell is available for use in the interim.