Microsoft Teams sprawl stays manageable with a few well-chosen controls

In almost every tenant I've worked in, Microsoft Teams became the main collaboration platform, and usually faster than anyone expected. The freedom that comes with it turns into disorder pretty quickly. New teams appear everywhere, names are cryptic or duplicated, workspaces get abandoned and nobody is sure who owns what. Even organizations with strict IT policies end up dealing with the consequences of uncontrolled growth in Teams and Microsoft 365 groups. The pain is real, and no single setting or policy will ever prevent it completely.

Restricting group creation often causes more problems than it solves

The first reflex is to limit who can create Teams and Microsoft 365 groups. Technically that's easy with group creation restrictions, which let you lock creation down to specific users or roles. I've seen it backfire, though. Approvals take too long, users get frustrated and come up with their own workarounds. People collaborate outside Teams or go back to old email threads because setting up a new team is too much hassle. In fast-moving departments like communications or development, heavy restrictions hurt productivity. Sometimes it's smarter to accept a bit of sprawl and put your effort into other areas.

My tip: If you do restrict group creation, make requesting a new team as easy as possible. Automate the approval workflow with Power Automate or set up a simple self-service portal. Whatever you choose, avoid bottlenecks and request backlogs.

Naming policies keep the Teams list readable as it grows

Without naming conventions, your list of teams turns into a mess fast. I've seen vague abbreviations, duplicate names and teams called "Test" or "Demo" that nobody remembers creating. With Microsoft 365 group naming policies you can enforce prefixes and suffixes, block forbidden words and even pull in user properties. The result is names like "PRJ-Marketing-2024" or "DE-Support-External", which tell you right away what a team is for. Don't overdo it, though. If the rules are too rigid or don't match how the business actually works, people will find ways around them.

A short PowerShell command sets the group naming policy

Set-AzureADDirectorySetting -Id <ID> -DirectorySetting @{ "Prefix" = "PRJ-"; "Suffix" = "-[Department]" }

This sets a fixed prefix and appends the user's department as a suffix.

Expiration policies clear out teams that nobody uses anymore

Old, forgotten teams are another big source of sprawl. Group expiration policies let you set a time limit (180 days, for example), after which owners are automatically asked to renew the team or let it expire. In practice, unused workspaces disappear quickly, and owners of active teams can extend them with a single click. Owners get reminders before anything is deleted, so nobody is caught off guard. Without a policy like this, zombie teams pile up, clutter the address book and confuse anyone trying to find the "real" place to work.

Sensitivity labels decide how far guest access reaches

Guest access is one of the topics people argue about most. Who is allowed to invite external users, and how do you stop sensitive information from leaking? Sensitivity labels for containers classify teams or groups, for example as "Internal", "Confidential" or "External Collaboration Allowed", and apply the matching access restrictions. For some labels you can block guest access entirely, and for sensitive projects you can require additional controls. When you combine guest access settings with labels, you contain the risks before they turn into incidents.

Two owners, archiving and ongoing training keep teams manageable

Ownership matters a lot. A team with only one owner is asking for trouble, because nobody can manage the group once that person leaves. I always recommend at least two owners, plus a script that runs regularly to find orphaned teams. I also prefer archiving unused teams over deleting them outright. Old projects stay available for reference, but they no longer get in the way of everyday work.

None of these governance rules work if people don't know about them. A single email announcement won't do it. Ongoing training, short videos or a clear FAQ on the intranet are far more effective. In my experience, the best results come when reminders go out regularly and the guidance is always easy to find.

The governance settings depend on each other in a fixed order

The flowchart below shows how these settings interact. It runs from the creation request through naming, labeling, guest access and expiration to archiving or retention. You can see the dependencies, and you can also see where things tend to go wrong.

flowchart TD
  Start["Group creation requested"] --> Naming["Naming policy applied"]
  Naming --> Labeling["Set sensitivity label"]
  Labeling --> Guest["Guest access allowed?"]
  Guest -- Yes --> Owner["Assign owners"]
  Guest -- No --> Owner
  Owner --> Expire["Expiration policy active?"]
  Expire -- Yes --> Renew["Owner receives reminder"]
  Expire -- No --> Used["Is team active?"]
  Renew --> Used
  Used -- No --> Archive["Team archived"]
  Used -- Yes --> Used

Figure: How the Teams governance settings connect and depend on each other

Teams governance never really reaches a finished state

If you treat Teams governance as a one-time setup, it will catch up with you. Every organization I've worked with needed its own balance of control and flexibility, and even with good policies in place, special cases keep coming up. What matters most is having clear rules you can enforce and reviewing them regularly. You'll never prevent sprawl completely. With the right combination of controls, though, you end up with a solid basis for teamwork instead of chaos.