Considerations on Setting up office365 groups

[Jaap Slot]

As I get a better insight in the use of Microsoft Office365 groups it becomes clear to me that the Office365 Group is an object in the Azure Active Directory. This object in conjubction with one or more different functions.

At first Office365 groups was an invention to replace distribution lists in Exchange. This new invention was so powerful that other productgroups als used it. Think about Planner and ofcourse Microsoft Teams. The functionality that was already in place also wanted to hook up with this new object, so Yammer and Sharepoint functionality was added. 

At the moment, to create an Office365 group it is only possible when creating a mainfestation of this in Office365 group. I think that in the near future other functionalities will be added or developed. 

Would it be feasable to create an Office365 group and add functionality to it instead of creating an Office365 group per manifestation?

[#2]

If you mean creating a Group and "ticking" features for it (conversations, Teams, Planner etc.), no.

This kind of functionality has been requested many times here, but it is neither available nor promised. 

[#3]

Salvatore is correct as always....You cannot think Group only as an Object in Azure AD...Groups is a cross service that user core O365 Services (EXO, SPO and Azure AD)

[#4]

Whilst i know that Office 365 Group is an AAD object I can never think about it in those terms because of all the automation that happens to synchronize the object with different Directories and the Automated provisioning that happens with this.

[#5]

So there is more to it than an entry in AAD. And more services are needed when creating an Office365 group. But once created, do in need to enhance it with every new manifestation of this phenomenon.

What is the rationale in it, to have so many manifestations of the same infrastructural object.

[#6]

@Jaap Slot

To summarize:

An Office 365 Group is an AAD object which could be "decorated" by a number of features, some of which are mandatory (meaning that they are always created when a Group is created - e.g. SPO modern team site) and others are optional (meaning that they are created only when explicitly requested - e.g. Teams). But, in any case, when one of the optional Group feature is activated, a Group is consequently created (together with its mandatory features).

[#7]

Thanks @Salvatore Biscari.

Do you by any chance have a link to a matrix or something about which things are mandatory on what manifestation and which things are only optional per manifestation?

With kind regards, Jaap

[#8]

No, unfortunately I don't have such a link.

Maybe @Juan Carlos González Martín could help...

[#9]

Check any of the @Christophe Fiessinger slides about Groups (Ignite 2016 or TechCommunity ones)...basically there are 3-4 pillars that are mandatory for Groups:

(1) Azure AD

(2) EXO

(3) SPO

(4) OneNote

[#10]

This is an infographic that I find helpful in explaining how an O365 AAD Object works. 

[#11]

I think Groups should be looked at as a collaboration tool (the same way you now look at Teams).

No way in heck business end users understand if I explain Groups as a membership service, but as a "collaboration in a box" package, that they can get behind.

I think it would behoove Microsoft to start labeling it and treating it as such, and that would help push user adoption and usage. Groups is way more useful in our organization than Teams because of how we work, but Groups has put an arbitrary ceiling on its own head IMO.

To me, Groups (as a product) = slow collaboration whereas Teams (as a product) = fast collaboration, both are ultimately accomplishing the same goal though.

[#12]

It would be so much easier if the membership service had a different name than the UI instantiation.