Last spring I ran a tenant audit for a financial services client that had deployed Teams three years earlier with minimal governance controls. The figure in the audit report that startled the IT director most was not the total team count (847). It was the share of those teams with no active members in the previous 60 days: 61 percent. Functionally, more than half the Teams environment was a ghost town.
This is Teams sprawl in practice. Not a dramatic failure, but a slow buildup of abandoned workspaces that steadily degrades the tenant's usability and enlarges the security and compliance surface area. Nobody caused it on purpose. It simply happens when growth outruns governance.
The Root Causes of Teams Sprawl
Sprawl traces back to a handful of root causes, and understanding them lets you design prevention strategies that actually work.
Unrestricted team creation. Teams proliferate when any user can create one at any time for any reason. Many spring up speculatively — "let me create a team for this project, maybe it'll be useful" — and are then abandoned when the project never materialises or shifts to a different channel.
No lifecycle process. Even well-intentioned teams become sprawl when nobody expects them to be cleaned up once they stop being active. Absent an expiration process or ownership accountability, teams simply accumulate.
Lack of discoverability. Unable to find an existing team for their purpose, users make a new one. This bites hardest in large organisations with poor team discovery — search returns dozens of similar-sounding teams, and rather than investigate, users create something fresh.
Duplicate communication channels. Some organisations run Teams alongside older collaboration tools that serve overlapping purposes (the file service team sites, the enterprise social service/the enterprise social service groups, workspaces in other chat tools). Out of habit or convenience, users create Teams counterparts of existing channels without retiring the old ones.
Prevention: Governing Team Creation
The most effective prevention strategy is a governance-controlled team creation process. Instead of open creation, teams come through a lightweight request process that:
- Asks the requester for a purpose statement
- Checks whether a team with a similar purpose already exists, catching duplicates early
- Assigns two owners or more at creation
- Applies naming conventions automatically
- Sets a classification and switches on the matching sensitivity label
- Starts the lifecycle clock: an expected end date is set and the expiration policy is triggered
- Require a duplicate check against existing display names and aliases before the request gets approved
- Record a review date on the request, so teams built for a single event are revisited once that event ends
Technically, the implementation can run anywhere from a simple request form filed with the IT helpdesk, through a the automation service flow that provisions teams automatically from form input, to a third-party Teams governance tool. The right choice turns on your organisation's scale and IT maturity.
Prevention: Making Existing Teams Easy to Find
Poor discoverability is a key driver of duplicate team creation: users who cannot find an existing team will build one. Raise discoverability and duplicate creation drops at its root.
Options on the technical side:
Enforce naming conventions. Consistent naming makes searching easier. "Finance-BudgetReview-2025" is far more findable than "Budget stuff."
Use a team directory. Larger organisations improve findability with a searchable team directory — a the file service page, an intranet section, or a dedicated Teams tab — listing every active team with a description. Some organisations build this with Power Apps or third-party tools.
Set teams to "public" where appropriate. Non-members cannot see private teams in search results, yet not every team needs to be private. Teams acting as department communication hubs, announcement channels, or knowledge repositories should generally be public, so interested users can find and join them without a separate discovery step.
Remediation: Clearing Out Sprawl That Exists
When you inherit a tenant that already has sprawl, remediation becomes a problem distinct from prevention. A few approaches:
Stale team audit. Teams usage reports — available in the Admin Center and via PowerShell — single out teams with no activity for 90+ days. Message the owners plainly: "We've identified this team as inactive. Please renew it or confirm that it can be archived." Attach a response deadline. Teams that get no response get archived.
Ownership audit. Produce a report of teams with fewer than two owners. For single-owner teams, approach the relevant manager to nominate a second owner or confirm the team can be archived. For ownerless teams, assign ownership through the admin process and start a review.
Duplicate team consolidation. Remediation is hardest when duplicate teams must be identified and consolidated, because it demands human judgement — the decision about which team survives and how content moves cannot be automated. You can make it easier: identify candidate duplicates (teams with overlapping membership and similar names), contact owners to establish which team is the active one, and offer guidance on migrating content from the duplicate into the primary.
Tracking Progress
A handful of metrics will show, over time, whether your sprawl prevention and remediation efforts are working:
- Active team total (activity within the last 30 days)
- Inactive team total (nothing in 90+ days)
- Teams without owners
- Teams with no expiration date set
- Teams created outside the provisioning process
Snapshotting these metrics monthly shows whether things are getting better. A falling trend in ownerless and inactive teams, together with a total team count that is stable or declining relative to user count, means the governance controls are working.
Sprawl Born From Integrations Rather Than Users
Blocking the "Create team" button slows down the people who would click it; it says nothing about the other creators. Teams show up whenever a cloud group is created, and groups are created by the task planner, by enterprise social service communities configured to provision a team, by the automation service flows, by migration tools, and by line-of-business apps using Graph. A tenant can advertise a locked-down creation policy and still gain dozens of teams a week.
A retailer of roughly 6,000 staff switched on a restricted creation policy and then watched the team count climb anyway. The sources: a store-opening flow that created one team per new location, plus a habit in the merchandising group of spinning up a the task planner group for every seasonal campaign. Neither path appeared in the Teams admin center's creation setting. The numbers only made sense once group creation was grouped by the application id in the audit log.
The audit log is where "who is creating these" gets answered. Filter team-creation and group-add events across a fortnight and group them by actor. Sync accounts, service principals, and human owners tell different stories and call for different controls. A service principal either gets an owner and a naming rule stamped at creation, or loses its permission. Leaving it unnamed is how orphaned teams pile up.
Discoverability cuts duplicate creation only when search genuinely returns the existing team. Vague, private teams get recreated because the requester cannot see them. A public team with a clear name, or a gallery of approved teams kept by each department, removes the excuse. Discoverability is no 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 any growing company. The useful figures are teams created per 100 employees per month, the share carrying two owners, and the share inactive past the lifecycle threshold. A cleanup that deletes a hundred idle teams yet leaves the creation rate untouched will be repeated next quarter.
Inventory every app registration holding Group.ReadWrite.All or comparable group-write rights, and name a business owner for each. 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 write the expiration and the two owners in the same run — creation without lifecycle is half a process. Duplicate detection must compare mail nicknames and aliases, 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 with no change to the creation paths is a project, while 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 matter only if the automation refuses to submit when they are empty. Duplicate teams are expensive because files split, so 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. Have every integration owner walk through a team creation in a test tenant once a year; demos reveal missing owners faster than diagrams. And a gallery of joinable teams needs an owner too, or it becomes another stale list.
