Why Your Approach to Microsoft Teams Governance is Wrong

Yes, you read that right. The title is not a question or suggestion, but a statement of fact: Your approach to Microsoft Teams governance is wrong.

Right now, you must be thinking I have some serious chutzpah to make such a statement, and you’d be correct – but that chutzpah is built on real-world experience working with organizations of all sizes and industries. 

And why is it that I’m saying the approach is wrong? Because of the fact that industry “experts” use the term “Teams governance” in the first place. No, I’m not being pedantic that it should be “Microsoft Teams governance”, I’m calling out the narrow-focus view that governance of the Microsoft Teams platform actually exists. While Microsoft Teams monitoring and reporting is important, it's one part of the whole of Microsoft 365 suite.

Let me explain. 

There’s no “I” in team 

This saying about teamwork and cooperation vs. selfishness means as much in the human world as it does when it comes to Microsoft Teams – because without the rest of the Microsoft 365 suite, Microsoft Teams can’t exist, literally. 

If ever there was a trust-fall exercise, nothing would epitomize it more than the reliance of Microsoft Teams on the rest of the Microsoft 365 suite. 

Without Exchange Online there is no calendar or storage of compliance records. 

Without SharePoint Online there is no files in Team channels. 

Without OneDrive there is no files in chat. 

Without Azure Active Directory there is no membership management or authentication with third-party apps and services. There is no ability to invite guests or be a guest. There is no conditional access. 

Without Endpoint Manager there is no securing of devices that access Microsoft Teams. 

Without Azure Information Protection there is no control of content inside Teams. 

Without Office there is no ability to move an email from Outlook to a channel, or the ability to edit documents, spreadsheets and presentations. 

Without Stream there is no recording of meetings. 

But it doesn’t stop there, because while the Teams part of Microsoft Teams sits atop of Microsoft 365 Groups (formerly known as Office 365 Groups), to do a number of other features within the Microsoft 365 platform such as Forms, Planner, and Power BI. Not to mention the other apps and services that connect and integrate such as Power Automate and Power Apps, Yammer, etc. (I actually wrote a lengthy tech doc for Microsoft about the interactions of Groups and workloads which goes into a fair bit of detail.) 

There are also a number of other Microsoft 365 features that sit behind the scenes which also offer crucial functionality to Microsoft Teams, such as Data Loss Prevention, Sensitivity Labels, Communication Compliance, Advanced Threat Protection, and so on. 

But what about “Teams governance”? 

Microsoft Teams has been generally available now for three-and-a-half years, and every time I watch a webinar or presentation, read a blog, or speak to a new client, the view of “Teams governance” is often limited to these three questions: 

• Who can create a Team? 
• How should we name it? 
• How long should it be around for? 

It’s at this point that I need to reach for my stress ball. 

To say that this is the extent of “Teams governance” isn’t just naïve, it’s wrong. Sure, some might recognize that there are other elements that need to be considered, but rarely do I see or hear anyone go into them. And that’s the part that is wrong. 

Yes, Microsoft Teams Reporting is very important. However, Microsoft Teams is not an entity unto itself. It is the sum of the parts underneath it and across the entire Microsoft 365 platform. As illustrated in the previous section, if you don’t address these – then you haven’t done your governance job. 

Let’s pick apart the three governance decisions many people rest on. 

Who can create a Team? 

Firstly, this isn’t about Teams. This is about Microsoft 365 Groups. You are not restricting who can create a Team, you are restricting who can create a Group. 

This affects SharePoint, Planner, Stream, Power BI, Yammer, Project, and others. 

By restricting who can “create a Team” you are potentially restricting other, legitimate, reasons for Group creation in other products across the Microsoft 365 platform. 

You need to think beyond just Team creation. 

How should we name it? 

Again, this isn’t about Teams – it’s about Microsoft 365 Groups. 

Unfortunately, our choices are limited here, because Microsoft only offers a single policy, it’s on or off for the entire organization without exception, and it requires a higher-level license. 

So, if you turn on a naming policy and use a prefix or suffix, that will be apply to ALL Microsoft 365 Groups. 

I worked with one organization that set a naming policy to use the prefix of “GRPO365_” which made me want to weep. Think about this from an end-user’s perspective; navigating to your project Team which has a name of “GRPO365_Office Refurbishment”. How is this helpful? 

Also, what does the prefix “GRPO365_” actually offer that is beneficial? Sure, you can differentiate it from a security group, but why does that matter? An administrator can do this easily from one of several different admin and reporting interfaces. An end user doesn’t care. 

And what would that organization do now that they are no longer called “Office 365 Groups”, but “Microsoft 365 Groups”. Do they keep the old prefix or go with a new prefix of “GRPM365_”? And if the latter, do they go through and update the previous Group names? 

Another alternative I’ve seen is the suffix approach, where any Team is given the suffix of “Team” so that people can tell it’s a Team. 

Why? 

Surely, I could tell it’s a Team when I access it in Microsoft Teams. And most times, suffixes aren’t visible as they get cropped when displaying names through various interfaces. Also, who cares that it’s a Team? Because it’s also a SharePoint site, an Exchange mailbox, a Stream group, a Power BI workspace, etc. What if I start using Planner or the SharePoint site heavily? How does having a suffix of “Team” offer any relevance to the fact that I’m using functionalities outside of Microsoft Teams? 

How long should it be around for? 

Congratulations, this means you’ve discovered the expiration policy! What’s your prize? Data loss. 

That’s right! Because it’s not just about how long until the expiry policy kicks in, it’s actually about what happens to the data in the Team (and subsequently the Group) when the expiry policy does its job and deletes the Team. (Another tech doc I wrote for Microsoft explains the options available for offboarding Group content and services.) 

What’s that you say? You’ve configured retention policies? Fantastic. You’ve addressed a small handful of the capabilities and data services your people are using. 

Retention policies only cover Exchange, SharePoint, and conversations in channels. What about any Planner boards you had? Project plans or roadmaps? Form submissions? Meeting recordings in Stream? Your retention policy doesn’t cover those. And you can’t programmatically export / back up the data from all of those locations either. 

And don’t believe those vendors that offer solutions to back up or migrate Teams – they can only cover some of the Group-connected components because some of the others don’t offer APIs that allow vendors to connect in the first place.. 

The challenge is, that you as an IT admin have no way of knowing how much any of these smaller apps and services are being utilised, because there is no reporting. 

Oh, and before I forget – what happens to the guests your Team members invited when the Team is deleted? Nothing. They stay in your Azure Active Directory until an admin removes them. 

Why so mean? We’re trying our best! 

You are, and kudos to you for even considering governance. Very few organizations I speak to have even thought about it, only a handful more have even raised the previous three questions. As mentioned previously, those previous three questions are just the only options available in Azure Active Directory when it comes to Microsoft 365 Groups management. 

The problem is that the approach to “Teams governance” is as naïve as SharePoint governance is in the world of Microsoft 365. The Microsoft 365 platform is broad, and so too are some of the services within it. Again, yes Microsoft Teams Reporting is important but, thinking of Teams only is too narrow-minded; it’s just one service (albeit a big one) in this ever-evolving productivity platform. 

Starting with Teams when thinking about governance is practically putting the cart before the horse. Because you’ve put a gigantic cart out in front, with a pony behind it. 

So, what’s the better approach? 

Firstly, separate “Teams” from “Microsoft Teams”. Teams inside Microsoft Teams are built on top of Microsoft 365 Groups. So, when we think of them, we need to consider everything else a Group is connected to and can do. 

There are some things we can control through technology, and others through policy and training. There are also some things we can administer at the platform level and others can only be done at the individual Team level. 

At the Team level 

For example, channel creation is one of my biggest bugbears. People create channels like they are folders – but they’re so much more than that. They also add tabs and apps whenever they feel like it. So, think about whether Team members should be able to add/modify/delete channels, tabs, apps, etc. 

A colleague of mine created a channel in a Team with a Form in it because he wanted a central place to have information about a particular workshop type. In 7 months, there have only been two posts in there (both from him), with absolutely no replies. Instead the conversations about those workshops being had in other channels that are actually more relevant. 

I had a scenario with a client where a member of a Team removed a Planner tab, but in doing so actually deleted the underlying Planner board within it. A board created by an executive, that was now lost and unrecoverable. Remember what happened when you deleted a file or folder off a network drive, the panic you would feel? At least you could go to IT and have them recover it (most of the time). That’s not the case with Planner boards. You delete them – they’re gone for good. 

Team owners need to be accountable for their Team. Ensure the Team has a purpose and reason to exist as a Team, set a structure that makes sense to everyone, explain it in the wiki, and then limit access to functionality. 

Additionally, not all Teams are created equal – consider different templates and functionality sets based on requirements. 

At the Microsoft Teams level 

The Microsoft Teams platform has A LOT of different options available to it. Controls around private channel creation, meetings, Live Events, messaging, apps, and the platform itself. There’s also controls around what guests can do. 

All of these need to be evaluated, considered, and adjusted based on needs. Small things can make a big difference. 

Take the ‘shared notes’ capability in meetings. I recommend every client turn it off at the global level, and when I explain why – they all agree. That one setting has a flow-on effect to training and adoption, but also the replacement solution requires further governance, training, and adoption to make it work. 

At the Microsoft 365 Groups level 

There are options under the surface that are Groups-specific that need to be addressed, such as visibility, connectors, guest access, connected services, other apps, etc. Should you control this globally through your own provisioning model? How do you then retain control of those settings afterwards? 

At the content level 

Think about information management, classification, labelling, location, retention, transmission, etc. 

Do you have a records management system that needs to be incorporated? Does it integrate with Microsoft Teams? How well? And how will you address the aspects that can’t be integrated such as chats, Planner boards, wiki pages, meeting recordings, etc. 

At the security & compliance levels 

Think about guests – not just whether you want to be able to interact with them, or who should be able to invite them, but more so where should they be allowed to be added, and what do you do with them over time? They’re not collector cards that grow in value – they are security holes. 

Think about sharing levels, guest permission levels, audit history, etc. 

Stop it, my head hurts! 

And it should. Governance is not something to be taken lightly. It’s not something to do in isolation around a single product. It’s also not limited to the options provided to you by the technology you are using. It’s not set and forget. 

In some cases, additional functionality and capability will need to be added through a variety of avenues such as scripting, third-party tools, training, manual process, and policy. 

Also, when talking about Microsoft 365, don’t just focus on what was Office 365 – include Azure AD and Endpoint Manager as part of the framework, they offer extra levels of control and security. 

Please, stop focusing on “Teams governance” and instead look at governance across the entire Microsoft 365 platform – and don’t leave a single stone unturned!