In the spring of last year, I ran a tenant audit for a financial services client that had deployed Teams three years earlier with minimal governance controls. The number in the audit report that surprised the IT director most wasn't the total team count (847). It was the percentage of those teams with no active members in the last 60 days: 61 percent. More than half the Teams environment was, functionally, a ghost town.
This is what Teams sprawl looks like in practice. Not a dramatic failure — a slow accumulation of abandoned workspaces that gradually degrades the tenant's usability and increases security and compliance surface area. Nobody caused it intentionally. It just happens when growth is faster than governance.
What Causes Teams Sprawl
Sprawl has a few root causes, and understanding them helps you design prevention strategies that actually work.
Unrestricted team creation. When any user can create a team at any time for any reason, teams proliferate. Many are created speculatively — "let me create a team for this project, maybe it'll be useful" — and then abandoned when the project doesn't materialise or moves to a different channel.
No lifecycle process. Even well-intentioned teams sprawl if there's no expectation that they'll be cleaned up when they're no longer active. Without an expiration process or ownership accountability, teams just accumulate.
Lack of discoverability. When users can't find an existing team for their purpose, they create a new one. This is particularly common in large organisations where team discovery is poor — the search function returns dozens of similar-sounding teams, and rather than investigate, users create something new.
Duplicate communication channels. Some organisations have both Teams and older collaboration tools (SharePoint team sites, Yammer/Viva Engage groups, Slack workspaces) that serve overlapping purposes. Users create Teams counterparts to existing channels out of habit or convenience, without retiring the old ones.
Prevention: Controlling Team Creation
The most effective prevention strategy is a governance-controlled team creation process. Rather than open creation, teams are created through a lightweight request process that:
- Requires the requester to provide a purpose statement
- Checks for existing teams with a similar purpose (to prevent duplicates)
- Assigns at least two owners at creation
- Applies naming conventions automatically
- Sets a classification and enables the corresponding sensitivity label
- Starts the lifecycle timer (sets expected end date, triggers expiration policy)
- Require a duplicate check against existing display names and aliases before the request is approved
- Record a review date on the request so teams created for a single event are revisited when that event ends
The technical implementation can range from a simple request form submitted to the IT helpdesk, to a Power Automate flow that provisions teams automatically based on form input, to a third-party Teams governance tool. The right choice depends on your organisation's scale and IT maturity.
Prevention: Making Existing Teams Discoverable
A key driver of duplicate team creation is poor discoverability. If users can't find an existing team, they'll create one. Improving discoverability reduces duplicate creation at the root.
Technical approaches:
Enforce naming conventions. Consistent naming makes it easier to search. "Finance-BudgetReview-2025" is much more findable than "Budget stuff."
Use a team directory. For larger organisations, a searchable team directory (a SharePoint page, an intranet section, or a dedicated Teams tab) that lists all active teams with descriptions improves findability. Some organisations use Power Apps or third-party tools to build this.
Set teams to "public" where appropriate. Private teams are invisible in search results for non-members. Not all teams need to be private. Teams that serve as department communication hubs, announcement channels, or knowledge repositories should generally be public so that interested users can find and join them without a separate discovery step.
Remediation: Cleaning Up Existing Sprawl
If you're inheriting a tenant with existing sprawl, remediation is a separate problem from prevention. A few approaches:
Stale team audit. Use Teams usage reports (available in the Microsoft 365 Admin Center and via PowerShell) to identify teams that have had no activity for 90+ days. Contact the owners with a simple message: "We've identified this team as inactive. Please renew it or confirm that it can be archived." Set a response deadline. Teams without a response get archived.
Ownership audit. Run a report of teams with fewer than two owners. For single-owner teams, find the relevant manager and ask them to nominate a second owner or confirm the team can be archived. For ownerless teams, use the admin process to assign ownership and initiate a review.
Duplicate team consolidation. Identifying and consolidating duplicate teams is the hardest part of remediation. It requires human judgement — you can't automate the decision about which team to keep and how to migrate content. But you can make it easier by: identifying candidate duplicates (teams with similar names and overlapping membership), reaching out to owners to determine which team is active, and providing guidance on how to migrate content from the duplicate to the primary.
Measuring Progress
Track a few metrics to measure the effectiveness of your sprawl prevention and remediation efforts over time:
- Total active teams (teams with activity in the last 30 days)
- Total inactive teams (no activity in 90+ days)
- Ownerless teams
- Teams without an expiration date set
- Teams created without following the provisioning process
Monthly snapshots of these metrics give you a picture of whether things are improving. A downward trend in inactive and ownerless teams, combined with a stable or declining total team count (relative to user count), indicates that the governance controls are working.
Sprawl That Comes From Integrations, Not From Users
Blocking the "Create team" button slows the people who click it. It does nothing about the other creators. Microsoft Teams appear whenever a Microsoft 365 group is created, and groups are created by Planner, by Viva Engage communities configured to provision a team, by Power Automate flows, by migration tools, and by line-of-business apps using Graph. A tenant can show a locked-down creation policy and still gain dozens of teams a week.
A retailer with about 6,000 staff turned on a restricted creation policy and watched the team count keep rising. The source was a store-opening flow that created a team per new location, plus a Planner habit in the merchandising group that spun up a group for every seasonal campaign. Neither path showed up in the Teams admin center's creation setting. The count only made sense after group creation was grouped by the application id in the audit log.
The audit log is the right place to answer "who is creating these". Filter group-add and team-creation events for a fortnight and group by actor. Human owners, service principals, and sync accounts tell different stories and need different controls. A service principal either gets a naming rule and an owner stamped at creation, or it gets its permission removed. Leaving it unnamed is how orphaned teams accumulate.
Discoverability reduces duplicate creation only if search actually returns the existing team. Private teams with vague names will be recreated because the requester cannot see them. A public team with a clear name, or a gallery of approved teams maintained by each department, removes the excuse. Discoverability is not a substitute for a creation gate. It lowers the number of requests that should have been joins.
Measure sprawl as a rate, not as a stock. Total teams will rise in a growing company. The useful figures are teams created per 100 employees per month, the share with two owners, and the share inactive past the lifecycle threshold. A cleanup that deletes a hundred idle teams and does not change the creation rate will be repeated next quarter.
Inventory every app registration with Group.ReadWrite.All or similar group-write rights, and name a business owner for each one. Give integration-created teams a prefix that identifies the system, so they can be filtered out of the human sprawl report. When a flow creates a team, it should also write the expiration and the two owners in the same run. Creation without lifecycle is half a process. Duplicate detection should compare aliases and mail nicknames, not only the display name people see in the client. Publish the creation numbers to the same managers who ask for new teams. Demand drops when the count is visible. A one-time purge without a change to creation paths is a project. A change to the paths is the control. Count teams created by each service principal monthly. A sudden jump is a new flow, and new flows rarely include owners. The creation form's mandatory fields only matter if the automation refuses to submit when they are empty. Duplicate teams are expensive because files split. A search for near-identical names is worth running before the quarterly cleanup. Public teams that are hard to find will be recreated as private teams. Fix the name before you blame the requester. Sprawl targets should be a rate per hundred employees. An absolute cap punishes a growing organisation for growing. When you delete a duplicate, move the files first and leave a pointer in the surviving team for a month. Ask each integration owner to demonstrate a creation in a test tenant once a year. Demos reveal missing owners faster than diagrams. A gallery of joinable teams needs an owner too, or it becomes another stale list.
