The first thing to understand about Teams retention policies is that the Teams Admin Center is not where you configure them. They live in the compliance portal, under Data lifecycle management > the cloud suite. For IT administrators who can find the Teams Admin Center but cannot pin down where a retention schedule gets defined, this is a genuine stumbling block.
The second thing to understand is that Teams retention policies do not behave like file service retention policies, despite Teams leaning on the file service and Exchange for the storage underneath. Teams chat messages sit in Exchange mailboxes, and channel messages are kept there too. Even so, the retention logic applied to Teams content is not ordinary mailbox retention, and the two should not be conflated.
Where Teams Content Actually Lives
Understanding Teams retention starts with understanding where the content physically sits:
- Teams private chat messages sit inside the mail service mailboxes of the people taking part, in hidden folders that the mail client never displays.
- Teams channel messages sit in the mail service mailbox of the cloud group that backs the team, within hidden group mailbox folders.
- Teams meeting chat messages follow the private-chat pattern and are held in the mailboxes of the participants.
- Files shared in Teams reside in the file service for channel files, or in the personal file store for private chat files. Retention for them comes from the file service and personal file store policies rather than from anything Teams-specific.
- Meeting recordings and transcripts live wherever the underlying file sits, being the organiser's personal file store or the channel site, so the file service and personal file store retention applies instead of the Teams chat retention locations.
- Copilot interactions in Teams show up as their own location in newer retention policies. Leave that location unticked and those interactions land on a different schedule from the chat around them, which is something records teams almost never intend.
That architecture matters for retention, because Teams retention policies act on the Exchange-resident copies of messages rather than on the Teams interface itself. Strip a Teams message away, whether a user does it or a retention policy does, and it disappears from the Teams UI while the compliance copy in Exchange may well survive, according to how retention was configured.
Configuring a Teams Retention Policy in the compliance portal
Navigate to compliance portal > Data lifecycle management > Retention policies > New retention policy. The essential steps are these:
- Give the policy a name, plus a description that makes its purpose explicit, such as "Teams Chat 3-Year Retain Delete".
- Settle what gets retained or deleted. You can hold content for a fixed span and then remove it, hold it with no end date, or simply delete it once a period elapses with no preservation beforehand. Your regulatory obligations decide which of the three applies.
- Select the locations. Tick "Teams channel messages" and/or "Teams chats and Copilot interactions." Coverage can span every team or a chosen subset, and individual users can be included or left out for Teams chats.
- Set the retention period and the action. State how long content is held, in days, months or years, and then what follows: removal, or nothing at all, which means keeping it permanently.
Retain or Delete: Telling the Outcomes Apart
Three outcomes are available from a retention policy:
- Retain and delete: Content survives the retention window and is then disposed of automatically. Right for organisations obliged to hold records for a set term, seven years for financial records for instance, before getting rid of them.
- Retain only (indefinitely): Content is held with no expiry and nothing is removed automatically. Useful under legal hold, or for organisations that prefer to keep records for good.
- Delete only: Content is wiped automatically when the stated period runs out, with no preservation guarantee beforehand. Handle cautiously, because this serves data-reduction aims rather than retention compliance.
How a retention policy differs from a legal hold
A retention policy looks forward, acting on content according to its age. A legal hold reacts to events, preserving specific content regardless of what any retention policy dictates. Where content sits under both a deletion-minded retention policy and a legal hold, the hold prevails: the content remains until the hold comes off, notwithstanding the policy's call to delete.
Common Mistakes
Attempting to cover Teams retention through Exchange mailbox policies. Administrators sometimes place a retention policy on the Exchange mailbox hoping it will catch Teams chats. For Teams content that does not behave correctly, because Teams chat messages occupy a dedicated subfolder structure in Exchange and are handled differently from regular mail. For Teams content, rely on the purpose-built Teams locations in the compliance portal, always.
Assuming that a delete in Teams destroys the data. A user who deletes a Teams message sees it leave the Teams interface within seconds. The compliance copy in Exchange, however, stays for as long as the retention policy allows. eDiscovery searches keep surfacing those "deleted" messages while they remain inside the retention window. Nothing is broken, since that is the compliance model working as designed, but it catches out users who believe deletion is final.
Never validating the policy scope. Where a Teams retention policy targets particular teams rather than every team, check that those teams really are being picked up. A misconfigured scope filter can leave a policy silently applying to nothing whatsoever. Once it is created, look at the policy status in the compliance portal and confirm it reads "Success" across the locations you anticipated.
What It Does to Your Compliance Score
Compliance Manager in the compliance portal tracks whether suitable retention policies exist across the different data categories your organisation holds. Configuring Teams retention lifts your compliance score on the data lifecycle management controls. And where a framework such as ISO 27001, SOC 2 or HIPAA is in play, evidence that retention policies are documented and configured is generally compulsory.
When a Retention Policy Wipes the Working Record
Teams retention can be aimed at the wrong outcome with very little effort. A policy set to delete channel messages after 90 days will delete them, including in teams that hold the only surviving copy of an operational decision. The compliance portal reports success throughout. The business finds out only when someone hunts for a decision taken last quarter and hits a hole.
A freight brokerage of about 600 users pushed a one-year delete policy over every Teams channel message, because a template described one year as "standard". Its dispatch channels were the live record of rate agreements, with no duplicate held in any records system. By month thirteen, supervisors could no longer rebuild why a lane carried the price it did. The policy had gone onto all teams, which is the fastest option in the wizard and the wrong scope.
Fit the retention scope to the teams the schedule actually covers. A brief delete window may suit social or disposable channels and be wholly wrong for anything the business would reach for in a dispute. Where the schedule says "keep seven years", the policy has to retain for seven years, and the in-scope teams must be the ones that truly hold that record. Naming a policy after the schedule while scoping it to all locations is exactly how the schedule lands on the noise and skips the record.
User deletions and retention deletions are separate events, and staff need that said plainly before the policy goes live. A user delete conceals the message in the client while the compliance copy rides out the retention period. A retention delete erases the copy as well once the period expires. Anyone previously told that "nothing is ever truly deleted" will be wrong the moment a delete action is in place, and wrong in front of a customer.
After enabling the policy, monitor its status until it reports success, then run a content search in a test team for a message you know should still exist and for one that ought to have aged out. A policy stuck in pending or error does neither job. The wizard finishing is not the same as the policy running.
Avoid stacking a short delete policy and a long retain policy on one location without establishing which action wins. Consult the precedence notes for the locations you selected, and prove them by test. Channel retention and private chat retention are distinct locations. Listing only channels leaves one-to-one chats on a different clock. Hold continues to outrank retention: a team under legal hold will not shed content merely because a delete policy reached its date. Changing the retention period afterwards does not resurrect whatever an earlier delete action already removed. Name the policy after the schedule and the location, never after whoever built it. Brief the records manager on which Teams locations exist. A schedule drafted for email alone gets applied badly unless somebody translates it. Treat a retention policy in an error state as though it were missing, and read the status column rather than taking comfort from the existence of the policy object. Test teams need a clock you can wind forward, or you spend a year waiting to see a delete. Prove a short period on a test location before you trust the production period. Record scope exclusions in the change record by team name and id. Files and messages may intentionally sit on different schedules; if they do, the records schedule should say so in those terms. Tell users, in the same note that announces the policy, that the client delete is not the retention delete. Where automation creates a team, settle which retention policy it falls under before the first message is posted. A policy that retains forever still needs an owner. Forever is a decision, and decisions get revisited as storage and risk shift.
