Group Creation, Naming & Expiration
Control who can create teams, enforce consistent naming conventions, set expiration policies for stale teams, and understand where Teams stores content.
Governing team creation and lifecycle
Imagine your office lets anyone book a meeting room. Within a month, there are 500 rooms booked — half are empty, names are confusing (“John’s thing,” “Test 123”), and nobody cleans up after themselves.
That’s what happens in Teams without governance. Group creation policies control who can create teams (not everyone needs to). Naming policies enforce consistent names (“Project-Phoenix” not “test123”). Expiration policies automatically clean up teams nobody uses — owners get a renewal notice, and if they ignore it, the team expires.
Where Teams stores content
Teams content is distributed across several Microsoft 365 services:
| Content Type | Storage Location | Governed By |
|---|---|---|
| Channel messages | Microsoft 365 group mailbox (Exchange Online) | Teams retention policies |
| Chat messages (1:1, group) | Participants’ Exchange Online mailboxes (SubstrateHolds) | Teams retention policies |
| Channel files | SharePoint document library (team site) | SharePoint policies |
| Chat files | Sender’s OneDrive | OneDrive policies |
| Meeting recordings | OneDrive (non-channel) or SharePoint (channel meetings) | SharePoint/OneDrive policies |
| Meeting transcripts | OneDrive (non-channel) or SharePoint (channel meetings) | SharePoint/OneDrive policies |
| Wiki/Loop pages | SharePoint | SharePoint policies |
| Team membership and settings | Microsoft 365 Group (Entra ID) | Entra ID group policies |
| Planner tasks | Planner service | Planner retention |
| OneNote notebook | SharePoint | SharePoint policies |
Key exam point: There’s no single “Teams storage.” Content is distributed. This means governance must span multiple services — a retention policy for Teams messages doesn’t cover files (that’s SharePoint), and a SharePoint sharing policy doesn’t cover chat text.
Restricting team creation
By default, every user can create a Microsoft 365 Group (and therefore a Teams team). In large organisations, this leads to sprawl — hundreds of unused teams with confusing names.
How to restrict creation
Restriction is configured in Microsoft Entra ID by limiting M365 Group creation to a specific security group:
- Create a security group (e.g., “Teams Creators”) containing users allowed to create teams
- Use Microsoft Graph PowerShell to update the Group.Unified directory setting:
- Set
EnableGroupCreation = false - Set
GroupCreationAllowedGroupId = <security-group-object-id>
- Set
- Only members of the specified security group can create new teams
Important: This restricts creation of ALL Microsoft 365 Groups — not just Teams. Users outside the group also can’t create Groups in Outlook, SharePoint, Planner, or Yammer. Global Administrators can always create groups regardless.
Scenario: Kofi restricts team creation at Harbour University
Harbour University had 15,000 teams created in the first semester — 60% were duplicates or unused. Kofi restricts creation:
Security group “Teams Creators” members:
- IT team (10 people) — can create any team
- Department heads (50 people) — can create departmental teams
- Faculty (5,000 people) — can create class teams
Who CANNOT create teams:
- Students (50,000) — they join teams created by faculty
- Admin staff (except department heads) — they request via IT
This reduces team creation from 3,000/month to ~200/month. Kofi still uses Entra ID Premium P1 for the expiration policies to clean up stale class teams after each semester.
Naming policies
Naming policies enforce consistent team names across the organisation. Configured in the Microsoft Entra admin center → Groups → Naming policy.
Two components
| Component | What It Does | Example |
|---|---|---|
| Prefix/suffix | Automatically adds text or attributes to group names | Prefix: “Team-” + Department → “Team-Finance-Budget Review” |
| Blocked words | Prevents specific words in group names | Block “CEO,” “HR-Confidential,” profanity |
Prefix and suffix options
You can use fixed text or Entra ID attributes as prefixes/suffixes:
| Type | Examples |
|---|---|
| Fixed text | ”Team-”, “Dept-”, “-archived” |
| Entra ID attribute | Department, Company, Office, StateOrProvince, CountryOrRegion |
Example naming policy: Prefix = “Team-” + Department attribute, Suffix = ”-” + CountryOrRegion
- Result: “Team-Finance-Budget Review-AU” (for an Australian finance team)
Blocked words
Upload a CSV file of blocked words. If a user tries to create a team with a blocked word, they see an error message. This prevents:
- Offensive or inappropriate team names
- Misleading names (e.g., “Microsoft Official” created by a non-Microsoft team)
- Reserved terms (e.g., “Executive Board,” “Legal-Privileged”)
Licensing: Naming policies require Entra ID Premium P1 for at least one member of the group being created.
Expiration policies
Expiration policies automatically clean up stale teams. Configured in Microsoft Entra admin center → Groups → Expiration.
How expiration works
- Set an expiration period: 180 days, 365 days, or custom (minimum 30 days)
- Apply to: All groups, Selected groups, or None
- When a group nears expiration, owners receive email notifications (30 days, 15 days, 1 day before)
- If no owner renews the group → it expires and is soft-deleted
- Soft-deleted groups can be restored within 30 days by an admin or owner
| Feature | Behaviour | Notification | Admin Action |
|---|---|---|---|
| Active team (used regularly) | Auto-renewed — any activity resets the expiration clock | No notifications needed | None required |
| Inactive team (no activity) | Owners get email at 30, 15, and 1 day before expiration | Owner clicks 'Renew' in the email | If owner ignores, team expires after the period |
| Expired team | Soft-deleted — can be restored within 30 days | Admin gets notification (if configured) | Admin or owner restores from Entra ID or PowerShell |
What counts as ‘activity’? Visiting a channel, reading a message, using the team in any way. Activity auto-renews the expiration timer without any owner action.
Scenario: Kofi's semester expiration at Harbour University
Kofi configures expiration for class teams:
- Expiration period: 180 days (roughly one semester)
- Applied to: Security group “Class Teams” (all teams created from the class template)
- Not applied to: IT teams, department teams (these are permanent)
At the end of each semester:
- Class teams that are still active (students accessing notes) → auto-renewed
- Class teams with no activity → faculty owners get renewal emails
- Faculty who don’t renew → teams expire and are soft-deleted
- If a professor realises they need last semester’s materials → Kofi restores the team within 30 days
This automatically cleans up ~2,000 stale class teams per semester without manual intervention.
🎬 Video walkthrough
🎬 Video coming soon
Group Creation, Naming & Expiration — MS-700 Module 7
Group Creation, Naming & Expiration — MS-700 Module 7
~10 minFlashcards
Knowledge Check
Harbour University has 15,000 teams. Kofi wants to prevent students from creating new teams while allowing faculty and IT to create them. Where should Kofi configure this?
Sterling Financial configures a naming policy with prefix 'SF-' + Department attribute. Nadia, from the Compliance department, creates a team called 'Audit Review.' What will the team name become?
Next up: Archive, Restore & Access Reviews — how to archive inactive teams, restore deleted teams, and use access reviews to keep team membership current.