Where to create an Office 365 group?

Brass Contributor

Right now there are LOTS of places you can create a new 365 Group from.  Just to name a few I know of:

  • Azure AD - Directly create a group
  • SharePoint Team Site - Creates a group along with the site
  • Microsoft Teams - Creates a group along with the team (can also make team from existing group)

There are quite a few more ways that groups can get instanced, but the real issue here is the lack of symmetry.  When a group is created, it gets a SharePoint Team Site regardless of where you make it, but if you make the group as a part of the process of making a new team site you can also select a site design to apply to that site.  I have read that site designs can be applied to existing modern sites, but have yet to find out how to do that.


If you create a group in Teams, a team is added and linked to the group, but if you create a group anywhere else no team is added!  

 

I am trying to build a system where a new Office 365 Group for a new project is created, a specific SharePoint site design/template is provisioned, and a Team is provisioned.  Some other configurations are done using the site design script -> launch a flow feature.  

Can anyone help me understand where the "proper" place to first create a group is?  Especially so that there are no lingering loose connections between services?  This all seems like a bit of a mess right now. 

 

11 Replies

@Myles Gallagher Per your requirements:

I am trying to build a system where a new Office 365 Group for a new project is created, a specific SharePoint site design/template is provisioned, and a Team is provisioned.  Some other configurations are done using the site design script -> launch a flow feature. 

The fastest way to have MS Teams, SharePoint and office365 group provision at the same will be through Teams. (GUI or Powershell). As they are not additional steps.

References:

If you do it through SharePoint Online and then connect the site with a Team is an extra step. but would like to hear other opinions. Great question.

Totally agree since there is not a public Teams API yet you can use to create Teams
does creating an Office 365 Group through Teams allow to edit the ALIAS of that group? SharePoint Home allows this, which makes the SharePoint URL and the e-mail address more readable.
When creating the group through AzureAD, the alias is pretty much a guid@domain.com.

Being able to edit the SMTP address is something we are working on, with a ETA in the summer, please stay tune.

A mess right now?  It's been a mess for the 5+ years we've been using O365.

 

Just minutes ago I ran into an issue trying to create a SharePoint site collection.  Kept throwing an error saying access denied every time I submitted the new site collection form.  I'm a global admin, so I have access.

 

Turns out the Site Collection name I was trying to use is already an O365 group.  Of course it doesn't indicate that anywhere unless you go into the directory and search for it.

 

Everyday another annoyance in this environment.  There's so much inconsistency.  O365 is a hodgepodge of services thrown into a bucket.

Hi Ivan

 

Creating an Office 365 Group through Teams doesn't allow you to edit the alias of the group today. This is because the expectation is that users who create groups in Teams tend to work in Teams instead of Outlook, so showing Outlook relevant properties like email address would make little sense.

True for endusers, not quite correct for managed environments (aka SMB) where administrators still have control of what gets created and how it is named.

I would say this would be OK if teams existing in isolation, but the big selling point for Microsoft is not the quality of the software, but rather the scope of the platform; the integration with all of the office software.  While I agree Teams users should not really be bothered with email settings for setting up a chat based team, that's not really what they are setting up.  They are setting up an Office 365 Group which is a massive concept that has interplay with almost every other service Microsoft has available.  So whether they know it or not they are getting a SharePoint team site, a "shared mailbox", a planner plan etc.  

If a company has defined customizations to each of these services that greatly enhances (and enables) their use towards a company goal, then we need to be able to deploy these customization when appropriate.  

 

Someone making a "team" call it "Project A" for a project that will only really use MS Teams, might be on another team (Group) "Project B" that was created in and primarily uses SharePoint.  This person also uses outlook for communication because email isn't going anywhere.

 

The end result:

While this user is on SharePoint, they see their nice "Project B" site, but also this bare-bones, mostly useless other than for file sharing, "Project A" site that was auto-provisioned without any business process integrations.

While this user is in outlook they see their normal inbox, along with these "Group" inboxes that were auto-provisioned, potentially garbage, mail-addresses under "Groups".

 

I am all for empowering users to initiate their collaboration environment.  However, there needs to be a way to customize what that environment is at a global level.  I want employees to be able to spin up SharePoint sites, Teams, Plans, etc but I want it to incorporate the tools and structure that make those environments useful within the context of our business (powerapps, flow, powerbi, sharepoint lists/documents/templates/teams bots the list goes on!!!).

 

The scope of Office Groups is too big to treat so carelessly.

Hi Myles

 

Thanks for this detailed feedback. We've been cognizant of this exact same problem and are looking to actively solve it in the coming fiscal year. Controlling what resources get provisioned when you create a group from any of the Office 365 apps is on our priority list. However, this is an extremely hard engineering problem to solve so it might take a while.

That's good to hear, and thank you for your reply. I hope microsoft is able to meet that goal in that timeline. At the moment there seem to be at least enough hooks into the whole process to hack together some control, as Dan Gross posted. I don't presume to have a better vision/roadmap of the current situation than the engineers at microsoft, but as the Graph API is further developed with more/better hooks into the new cloud office infrastructure I do think users will end up solving these problems on their own, tailored to their needs. Some solutions better than others of course, but the future (REST/Web services) of customizing microsoft's products is much brighter than the past (VBA/COM)

More software devs use microsoft software than there are devs working for microsoft.