The first thing to know about retention policies for Microsoft Teams: they are not configured in the Teams Admin Center. They live in the Microsoft Purview compliance portal, under Data lifecycle management > Microsoft 365. This causes genuine confusion among IT administrators who find the Teams Admin Center but can't find where to set a retention schedule.
The second thing to know: Teams retention policies don't work the same way as SharePoint retention policies, even though Teams uses SharePoint and Exchange for underlying storage. Teams chat messages are stored in Exchange mailboxes; channel messages are also stored in Exchange. But the retention policy logic for Teams content is handled differently from standard mailbox retention, and the two shouldn't be conflated.
How Teams Content Is Stored
Understanding Teams retention requires understanding where Teams content actually lives:
- Teams private chat messages are stored in the Exchange Online mailboxes of the participants (in hidden folders not visible through Outlook).
- Teams channel messages are stored in the Exchange Online mailbox of the Microsoft 365 group that backs the team (in hidden group mailbox folders).
- Teams meeting chat messages follow the same pattern as private chats (stored in participant mailboxes).
- Files shared in Teams are stored in SharePoint (channel files) or OneDrive (private chat files). File retention is handled by SharePoint/OneDrive retention policies, not Teams-specific policies.
- Meeting recordings and transcripts follow the storage location of the file (the organiser's OneDrive or the channel site) and are covered by SharePoint and OneDrive retention, not by the Teams chat retention locations.
- Copilot interactions in Teams are called out as their own location in newer retention policies. Leaving that location unselected means those interactions follow a different schedule from the chat around them, which is rarely what the records schedule intended.
This architecture matters for retention because it means Teams retention policies target the Exchange-based copies of messages, not the Teams user interface directly. When a Teams message is deleted by a user or by a retention policy, it disappears from the Teams UI, but the compliance copy in Exchange may remain based on the retention configuration.
Configuring a Teams Retention Policy in Microsoft Purview
Navigate to Microsoft Purview compliance portal > Data lifecycle management > Retention policies > New retention policy. The key steps:
- Name the policy and give it a description that identifies the purpose (e.g., "Teams Chat 3-Year Retain Delete").
- Choose what to retain or delete. You can retain content for a period and then delete it, retain it indefinitely, or delete it after a period without retaining it. The choice depends on your regulatory requirements.
- Choose locations. Select "Teams channel messages" and/or "Teams chats and Copilot interactions." You can include all teams or specific teams. You can also include or exclude specific users for Teams chats.
- Set the retention period and action. Define how long to retain content (in days, months, or years) and what happens at the end: delete or do nothing (retain forever).
Retain vs Delete: Understanding the Distinction
A retention policy can have three effects:
- Retain and delete: Content is preserved for the retention period and then automatically deleted. Useful for organisations that need to keep records for a defined period (7 years for financial records, for example) and then remove them.
- Retain only (indefinitely): Content is preserved indefinitely. No automatic deletion. Useful for legal hold scenarios or organisations that prefer to keep records indefinitely.
- Delete only: Content is automatically deleted after the specified period. No preservation guarantee. Use this carefully — it's appropriate for reducing data accumulation, not for meeting retention requirements.
Retention policy vs legal hold
A retention policy is a proactive governance tool that applies to content based on its age. A legal hold is a reactive tool that preserves specific content regardless of retention policies. If content is subject to both a retention policy (that would delete it) and a legal hold, the hold takes precedence — content is preserved until the hold is released, even if the retention policy says to delete it.
Common Mistakes
Applying Teams retention through Exchange mailbox policies. Some admins try to apply retention to Teams chats by setting a retention policy on the Exchange mailbox. This doesn't work correctly for Teams content — Teams chat messages in Exchange are stored in a special subfolder structure that's handled differently from regular email. Always use the dedicated Teams locations in Microsoft Purview for Teams content.
Assuming deletion from Teams means data is gone. When a user deletes a Teams message, it disappears from the Teams interface within a few seconds. But the compliance copy in Exchange is preserved according to the retention policy. eDiscovery searches can find "deleted" messages as long as they're within the retention period. This is by design — it's the compliance model working correctly — but it surprises users who think deletion is final.
Not testing retention policy scope. When you configure a Teams retention policy to include specific teams (rather than all teams), verify that the targeted teams are being picked up by the policy. Misconfigured scope filters can result in a policy that silently applies to nothing. Check the policy status in Purview after creation to confirm it's in a "Success" state and covers the expected locations.
Compliance Score Impact
Microsoft Purview's Compliance Manager tracks whether your organisation has appropriate retention policies in place for various data categories. Configuring Teams retention policies contributes positively to your compliance score for data lifecycle management controls. If you're working toward a compliance framework (ISO 27001, SOC 2, HIPAA, etc.), demonstrating documented and configured retention policies is typically a required evidence item.
A Retention Policy That Deletes the Working Record
Retention in Microsoft Teams is easy to aim at the wrong outcome. A policy set to delete channel messages after 90 days will do that, including in teams that still hold the only copy of an operational decision. The compliance portal will report success. The business will notice when someone searches for a decision from last quarter and finds a hole.
A freight broker with about 600 users applied a one-year delete policy to all Teams channel messages because a template described one year as a "standard". Dispatch channels were the working record of rate agreements. There was no parallel copy in a records system. At month thirteen, supervisors could not reconstruct why a lane had been priced a certain way. The policy had been applied to all teams, which was the fastest option in the wizard and the wrong scope.
Scope retention to the teams that match the schedule. A short delete period may be right for social or transient channels and wrong for anything the business would want in a dispute. If the schedule says "keep seven years", the policy has to retain for seven years, and the teams in scope have to be the ones that actually hold that record. A policy named after the schedule and scoped to all locations is how the schedule gets applied to noise and missed on the record.
Deletion by a user and deletion by retention are different events, and staff should hear that in plain language before the policy goes live. A user delete hides the message in the client and leaves the compliance copy for the retention period. A retention delete removes it when the period ends, including the copy. People who were told "nothing is ever really deleted" will be wrong once a delete action is configured, and they will be wrong in front of a customer.
After the policy has been enabled, check its status until it shows success, then run a content search for a message you know should still be there and for one that should have aged out in a test team. A policy in a pending or error state retains nothing and deletes nothing. The wizard finishing is not the same as the policy running.
Do not stack a short delete policy and a long retain policy on the same location without understanding which action wins. Read the precedence notes for the locations you selected, and test them. Private chat retention and channel retention are separate locations. A policy that only lists channels leaves one-to-one chats on a different clock. Hold still beats retention. A team under legal hold will not lose content just because a delete policy reached its date. Changing the retention period later does not restore what a previous delete action already removed. Name the policy after the schedule and the location, not after the person who built it. Tell the records manager which Teams locations exist. A schedule written only for email will be applied badly if nobody translates it. A retention policy in error state should be treated as absent. Check the status column, not the existence of the policy object. Test teams need a clock you can move, or you wait a year to see a delete. Use a short period on a test location before the production period is trusted. Scope exclusions should be listed by team name and id in the change record. Files and messages can have different schedules on purpose. If they do, the records schedule should say so in those words. Users should be told the client delete is not the retention delete, in the same note that announces the policy. When a team is created by automation, decide which retention policy it will fall under before the first message is sent. A policy that retains forever still needs an owner. Forever is a decision, and decisions get revisited when storage and risk change.
