Walk through enough Teams tenants and you start to recognise the naming convention problem immediately. Teams called "Marketing," "Marketing 2," "Marketing Team," "Marketing - New," and "Marketing Department" — all in the same tenant, all with overlapping membership, nobody sure which one is the current one. Or the opposite problem: a rigid IT-imposed convention like "ABC-US-MKT-GEN-2024-Q3" that nobody can remember and everyone ignores.
Good naming conventions solve a real problem: they help people find the right team without having to ask. They also support governance by making the purpose and scope of a team clear from its name alone. But designing naming conventions that users will actually follow — and that remain meaningful as the organisation grows — is harder than it looks.
What Makes a Good Naming Convention
A good Teams naming convention has four properties:
Human-readable. Someone who wasn't part of the team creation should be able to understand roughly what the team is for from its name. "MKTG-Q3-Campaign-2025" is readable. "MKT-US-GEN-24Q3-A3B7" is not.
Consistent. The same structure should apply across all teams. Inconsistency — some teams using department codes, others using project names, others using free-form text — defeats the purpose.
Scalable. The convention should work for 50 teams and for 5,000. Conventions that rely on manual assignment of unique identifiers or sequential numbering tend to break down at scale.
Enforceable. The convention should be something you can actually enforce technically, not just as a policy statement. If you're relying entirely on user goodwill to follow the convention, it will drift.
Common Naming Convention Patterns
A few patterns come up repeatedly in enterprise Teams deployments:
Department-Purpose. Format: [Dept]-[Purpose] — for example, "Finance-BudgetReview" or "HR-Onboarding2025." Simple, readable, and works well for functional teams. Less good for cross-functional projects where no single department is the clear owner.
Project code-based. Format: [Project Code]-[Project Name] — for example, "PRJ-1042-ProductLaunch." Works well in organisations that already use project codes consistently. Requires integration with your project management system to be maintainable.
Location-based prefixes. Format: [Location]-[Department]-[Purpose] — for example, "NYC-Legal-MergerPrep." Useful for multinational organisations where location disambiguates teams with similar purposes. Adds length; can make names unwieldy.
Sensitivity-prefixed. Format: [Sensitivity]-[Purpose] — for example, "CONF-ExecutiveCompensation" or "INT-AllStaff-Announcements." Useful when the sensitivity level needs to be immediately visible. Requires a consistent, well-understood set of sensitivity prefixes.
Many organisations combine two of these patterns. A common combination is sensitivity prefix plus department-purpose: "CONF-Finance-BudgetForecasting" or "STD-HR-Onboarding2025."
Azure AD Group Naming Policy
Azure Active Directory (Entra ID) supports group naming policies that can enforce prefixes, suffixes, and blocked word lists across all Microsoft 365 groups — which means they apply to Teams as well.
To configure a naming policy in Entra ID:
- Navigate to the Azure portal or Entra ID admin center
- Go to Groups > Settings > Naming Policy
- Configure prefixes (can include Azure AD attributes like department) and suffixes
- Configure the blocked words list
- Save the policy and note the prefix or suffix that will be appended, including the separator character
- Create one test group with a name that should pass and one that should fail, and confirm both outcomes before announcing the policy
The naming policy applies when a user creates a Microsoft 365 group — which includes creating a Team. The prefix or suffix is added automatically to whatever name the user enters. The user cannot override it.
A typical configuration might force a department prefix (using the user's Azure AD department attribute) so that a team created by someone in the Finance department automatically gets "Finance-" prepended to the name they enter. The user types "BudgetReview" and the team is created as "Finance-BudgetReview."
Naming policy limitations
Azure AD naming policies apply to Microsoft 365 groups, but not to all team types in the same way. Channel names within a team aren't controlled by the group naming policy — you'd need to enforce channel naming standards through a provisioning tool or governance process, not through Entra ID policy. Also, Global Admins can bypass the naming policy when creating groups, so admins need to be aware of the convention and follow it manually for admin-created teams.
Handling Exceptions
Any naming convention will have legitimate exceptions. Cross-functional teams, temporary project teams, and executive workspaces may not fit neatly into a department-based prefix structure. Your governance framework should have a documented process for exceptions — who approves them, how they're tracked, and what happens to exception teams during lifecycle management.
A practical approach: maintain a list of approved naming convention exceptions in your governance documentation. When a team owner requests an exception, it's reviewed against the list of acceptable exception categories and approved or rejected with a documented rationale. This prevents exceptions from becoming the rule without requiring approval-by-committee for every deviation.
Renaming Existing Teams
If you're introducing naming conventions to an existing tenant, you'll inevitably face the question of what to do about teams that don't follow the new convention. Renaming them retroactively is disruptive — it changes the SharePoint site URL, the Exchange mailbox, and the team display name all at once.
A pragmatic approach: apply the naming convention to all new teams from a defined date, and work through a gradual migration of existing teams over time, prioritising the most active ones. Don't attempt a big-bang rename of all existing teams — the disruption isn't worth it unless you have a specific compliance reason to do so.
When the Naming Policy Meets an Existing Directory
A naming policy only stamps groups created after it is turned on. Microsoft Teams that already exist keep whatever display name they were given on day one, including the joke names, the client names, and the three teams all called "Project". The policy is a gate for new work, not a repair tool for the directory you already have.
In a construction company of about 900 users, the agreed pattern was CC-<ProjectCode>-<Function>. Facilities turned the policy on during a Friday change window. Monday morning the helpdesk had 40 tickets from site managers whose mobile clients showed the prefix twice, because a flow the PMO had built was already prepending CC- before the group was created. The blocked-word list then rejected a legitimate project code that collided with a banned substring. Both problems are predictable if the policy is tested against the real creation paths, not only against the Teams client button.
Blocked words need the same review as the pattern. A list copied from a generic template will reject office names, product names, and common surnames. Run the list against the current display names before enforcement. Every current name that would be illegal under the new list is either a rename candidate or a word that should not be blocked.
Prefixes also consume the 256-character display name budget and, more often, the patience of people reading a channel list on a phone. A prefix longer than the project code itself is a design error. If the goal is filtering in admin reports, a custom property or a consistent short code does that job without forcing every user to read an administrative code in the client.
Renames of existing teams do not rewrite the SharePoint URL or the underlying mail nickname in every case the way people expect. Tell owners what will change on screen and what will not change in links already sent to clients. A naming cleanup that breaks bookmarks will be rolled back, and the policy will be blamed for a communication failure.
Keep a one-page exception path for mergers, where the acquired company must keep a legacy prefix for a defined number of months. Custom blocked-word lists are not a substitute for sensitivity labels. A banned word does not stop a sensitive file from being shared. If creation is blocked for most users, the naming policy still matters for the admin and the automation accounts that are allowed to create. Review the policy after any Entra ID directory change. A custom attribute used in the pattern that is empty for contractors will produce teams named with a trailing hyphen. Document the test accounts used to prove the policy, and reuse them the next time the pattern changes. Announce the pattern with three real examples from the business, not with a syntax diagram alone. Hyphens and underscores are part of the pattern. Publish which one is required, because both will appear if you do not. Mail nicknames generated from the display name can collide after a prefix is added. Check the nickname, not only the name users see. A blocked word in the middle of a legitimate project code needs an exception process that is faster than a week's wait. When the pattern changes, do not rename every team in one night. Pilot the rename on a dozen teams and read the bookmarks that break. Contractors who create teams through a request form still need the pattern shown on the form, or they will invent a second one. Numbers-only names fail the pattern and fail human memory. Require at least one meaningful word alongside the code. The policy's error text is what users see. If it quotes an internal standard number and nothing else, they will open a ticket. Review the pattern with the people who read team names on a phone, not only with the people who designed the code.
