Tim Coalson is a Senior Consultant in the Transformation Practice at ThreeWill. Tim has been developing solutions on the SharePoint platform for over 15 years and has been a developer/consultant for over 30 years. Tim has been involved in migrating SharePoint on-premises farms to the Microsoft Cloud, Power Apps, and Power Automate (aka Flow) which are part of the Microsoft no code/low code solutions.
Microsoft Teams – Governance and Compliance Features
Microsoft Teams leverages Microsoft 365 (M365) groups as a foundation. When you create a new Microsoft Team, behind the scenes you are creating a new Microsoft 365 Group. Microsoft 365 Groups come with several Governance and Compliance Features to help manage the inevitable growth of the M365 groups that get created in conjunction with the creation of new Microsoft Teams.
Due to this tight relationship between Microsoft Teams and Microsoft 365 (M365) Groups, the Governance and Compliance settings of M365 groups will have a direct impact on users when they create new Teams. Following is a list of Governance and Compliance features that can be configured to help manage the underlying M365 groups. In addition, I have listed one Microsoft Teams-specific feature that I think you will find useful. The availability of some of these features will be dependent upon your M365 license
Group Naming Policy
The Group Naming Policy automatically interjects AD attributes or other Strings as a prefix and/or suffix to M365 Group Names to better manage M365 groups.
For example, a naming policy of GRP [Department][GroupName][CountryOrRegion] combines a string, “GRP” with the Department attribute from Active Directory as a prefix to the group name and the CountryOrRegion active directory attribute as the suffix. So, if the user entered “Project ABC” as the group name, the impact of the naming policy would be a group name value of “GRP Sales Project ABC United States”.
It is very important to note that group naming policies do not apply to several administrative roles such as the Global Admin, User Account admin, etc. So, you will need to test this policy using a non-admin user.
Blocked words, as the name implies, are the ability to prevent the use of specified words in M365 group names. The obvious uses of this feature would be to prevent profane or other offensive words from being used in group names. However, there are less obvious reasons that might dictate blocking certain words. One is the fact that email addresses are created based upon M365 group names.
In the example below, if I do not block the word “Legal” then a Microsoft Team can be created with the name Legal and an underlying M365 group will be created with an email address of [email protected]<domain.com>. This could be very confusing to someone searching the Global Address Book. They could easily mistake this for an email address to contact the company legal department and potentially send sensitive information to the wrong group.
Blocked words are managed through a cvs file and can contain a maximum of 5,000 words.
Similar to Naming Policies, Blocked Words do not apply to some administrative roles so this feature should be tested using a non-admin user.
Restricting Creation of M365 Groups
By default, everyone in your organization can create Groups. Anyone creating a Modern Team Site, a Planner Plan, a Stream Group, a Microsoft Team, etc. is creating an M365 group. While on one hand, this might be convenient to allow everyone to create M365 groups, it is not hard to imagine the sprawl of M365 groups that could be created over a period of time and the challenge to manage them effectively.
The creation of M365 groups can be restricted to only a certain group of people if desired. This will lead to more control and governance in your tenant, but does come at some cost of convenience for end-users. An M365 group can be created and those users who are allowed to create M365 groups can be added to this group. This group can then be given permissions via PowerShell by setting the “GroupCreationAllowedGroupId” property.
Microsoft 365 Group Expiration
M365 Groups can be configured to have a life of a specified number of days (180, 366). When that period of time expires, group owners will be automatically sent a number of emails that allow them to renew the group for another expiration interval. Groups that are actively in use are renewed automatically. If the expiration interval is reached without qualifying activity and a group Owner does not renew the group, the group and all the associated services (mailbox, SharePoint Site, Teams, Planner, etc.) will be deleted. This delete is a “soft delete” which means it can still be recovered for up to 30 days.
This type of expiration policy makes a lot of sense for groups that are related to Projects that normally have an active life of months to a few years.
Microsoft Teams Templates
A relatively new feature is the ability to create custom Team templates. A custom team template is a predefined team structure with a set of channels, tabs, and apps. Depending upon the types of teams in your organization, a standard template can be created for each type of team to create a predictable experience across Teams. Of course, Teams created with a template are just a starting point. Channels, tabs, and apps can be added or removed as desired to fit the needs of the Team.
Team templates can be created in the Teams Admin Center.
Once a template has been created, it will show up as an option during Team creation.
I hope you find some or all of these governance and compliance settings to be beneficial as you manage Teams and their associated M365 groups in your M365 Tenant. For more detailed information on this topic, I recommend a Pluralsight course by Vlad Catrinescu titled “Configuring Governance and Compliance for Microsoft Teams and Microsoft 365 Groups”.