In Microsoft Office 365 we are spoiled for choice when it comes to choosing a collaborative mechanism to work together with other people. Microsoft gives us a plethora of ways to work together, but making the right choice from the outset can be a tricky proposition. Firstly, let’s get the terminology right, so that when we’re talking with others about the constructs used we’re all on the same page.
Security Group
These are the old-fashioned security groups we know and love from Windows NT days, that moved into Active Directory and now are the cornerstone of grouping users together for permission purposes. They can sync to the Cloud via ADFS or Azure AD Connect and you can find them as a valid option today in your O365 Admin center. Security Groups are still useful, especially for Microsoft Project Online customers, as it’s the only way to organise the synchronisation of your resource pool.
Mail Enabled Security Group
Exactly as the name implies, it’s simply a group that can receive email. Mail Enabled Security Groups are useful for scenarios where you need to email a set of people who are grouped together primarily for permissions purposes.
Distribution Group
Distribution Groups are a Microsoft Exchange feature that is useful when you need to email a bunch of people – but really don’t need to secure anything with permissions for those people.
Dynamic Distribution Group (Exchange)
Microsoft Exchange has a feature that allows you to dynamically calculate the membership of distribution groups based on rules looking at the properties of the users.
Dynamic Security Group (AAD)
Not to be left out, Microsoft Azure AD has a similar group that allows you to create security groups where the membership is calculated based on rules.
Office 365 Public Group
The Microsoft Office 365 group – or as it is known in the back-end as a “Unified Group” is a way of bringing together a group of people and exposing a series of services to them like an Exchange mailbox, OneNote, Planner, and a SharePoint Document library. One of the major success stories of the O365 group, is that it’s easy for users to join groups themselves and then unsubscribe from the group when they no longer feel it is adding value. These groups are a great way of grouping people together for collaboration, and letting people focus exactly on what is important to them. Just worth noting that from an Azure AD point of view, they appear as a distribution group, so while there is a high degree of awesomeness exhibited, this is not a great way of grouping people together for permissions purposes.
Office 365 Private Group
Private groups have all the great features of public groups except that they add a modicum of security to the content within. The owner of the group (not necessarily a system administrator) decides who should be allowed into the group, and access to the various flavours of content within. If you have work you need to do with a group of users that doesn’t concern the rest of the company this may be a good choice, especially if you want to add Microsoft Teams functionality as discussed in a moment. Office 365 private Groups is great at keeping content out-of-the way of SharePoint search results and Delve until it is ready for release. Keep in mind, there are a few different ways the membership of an O365 group might change, so I wouldn’t recommend using it as a high-security workspace.
Microsoft Teams (Office 365 Private Group with Teams enabled)
Private O365 groups have the curious distinction as being the only group type for which the Microsoft Teams (the new chat-based work space) functionality can be enabled. Indeed, if you create a Microsoft Team, an O365 private group is created to embody the team. Microsoft Teams is a great reason to create these groups, but careful use is encouraged for the following reasons:
- Discoverability: Storing corporate knowledge in Private O365 groups or Teams may be hazardous as that knowledge is not accessible to the wider company, nor easily discoverable. In fact, the only place I have found to discover the existence of Private Groups of which I am not a member is via the Groups interface in Exchange Web Mail. This is especially important for users because if they don’t know a group exists, it’s very likely you will have users creating multiple private groups or teams for the same purpose.
- Conversation confusion: As mentioned earlier, a Microsoft Team is still an O365 Private group, which means (somewhat confusingly) that there is an O365 Group “Conversation” element to the group that is not surfaced in the Microsoft Teams user interface. This non-Teams conversation for your group can be seen in Outlook and in the Webmail client, but is likely to be ignored by Team participants.
- Planner accessibility: Microsoft Teams can have multiple Microsoft Planner plans (tabs) attached. This facility is not currently supported for Office 365 Groups without Teams enabled and the additional plans created for Microsoft Teams are not navigable through the normal Microsoft Planner user interface.
- Guest Access: One of the great features of Office 365 groups is the ability to invite ‘guests’ from outside your company to participate in the collaboration. Consider that while guests can participate in Conversations, Files and OneNote they cannot participate in Teams, or Plans.
Office 365 Public/Private Group with new Framework Site attached
One of the more recent collaborative mechanisms to emerge is creating a new-style SharePoint Framework Site with an Office 365 group attached and something that anyone can do in O365. This option creates another hybrid O365 group type that has an advanced SharePoint Framework site attached but doesn’t have a Microsoft Team. The “modern” pages of the SharePoint Framework sites can also be retrofitted to existing webs elsewhere in SharePoint, but it is not yet clear if sites attached to existing O365 groups will get this new functionality automatically enabled.
Confused Yet? That’s the reason for this blog post; to decipher all the options, so you can make an informed decision about the way you collaborate.
By James Boman
Dev Lead for Sensei Product Development, James has been working as a commercial software developer since 1993, and joined Sensei in 2010. James manages the product development team ensuring Sensei is at the forefront of technology providing a modern platform for work management that is scalable, performant and maintainable.
Stay connected with Sensei
Follow us on LinkedIn for a steady flow of fresh, engaging and insightful content on upcoming webinars, new release blog posts and thought leadership all within the project, portfolio & work management space.
