Teams call records left chat retention policies in late April 2026: the replacement policy is PowerShell only

Since late April 2026, a newly created Teams call data record is governed by one thing only, a retention policy for the Teams call logs location. That policy can be created only in PowerShell, it is read only in the Microsoft Purview portal, and it covers nothing created before it went active. The chat policy that used to cover them stays enabled and keeps deleting chat messages, and no page read describes any error or warning being raised when it stops covering call data records.

Last verified: 2026-08-20.

What changed

Microsoft's Create and configure retention policies page, read on 2026-08-20, states it in one sentence: "Going forward, new CDRs are supported only when you create a retention policy for Teams call logs." Records already inside a chat policy stay there: "CDRs included in previous Teams chat retention policies continue to be managed by those same policies." The exposure starts at the changeover.

Three further sentences on that page each widen the interval. On creation: "This separate retention policy for call logs can be created and modified only by using PowerShell." On scope: "The policy applies only to new call logs that are created after the policy is configured and active." On timing: "When you create and submit a retention policy, it can take up to seven days for the retention policy to be applied". The first two sit under a subsection headed Retention policy for Teams call logs, and the third under a separate section headed How long it takes for retention policies to take effect. What sits under the subsection headed Known configuration issues for Teams retention policies is the changeover itself, which is not where a retention schedule gets reviewed.

Who is affected

Not every tenant. One whose chat policy carried no delete action has no schedule that stopped running. The exposed tenant is the one whose chat policy was delete only, or retain and then delete: it was deleting call data records on a cadence until the changeover and has not been since.

The direction of the failure is where a careful reader goes wrong. Microsoft's Learn about retention for Microsoft Teams page states the default without qualification: "By default, Teams call logs are retained indefinitely." The same page describes a workload where "deletion is the only applicable action". The uncovered band is not where evidence went missing, it is where deletion stopped happening, which puts the finding under storage limitation rather than discoverability.

flowchart TD
  accTitle: Where one Teams call data record lands, before and after the late April 2026 changeover
  accDescr: A vertical timeline of one record. Created before the changeover, it stays with the Teams chats policy and is still deleted on that schedule. Created after it, no policy claims it and it is retained indefinitely. A call logs policy can be submitted only in PowerShell and takes up to seven days to apply, after which it covers later records only, so the earlier interval stays open.
  A[Late April 2026 changeover] -->|Created before| B[Teams chats policy keeps it]
  A -->|Created after| C[No policy claims the record]
  B --> D[Deletion runs on schedule]
  C --> E[Retained indefinitely]
  E --> F[Call logs policy, PowerShell]
  F --> G[Up to seven days to apply]
  G --> H[Covers later records only]
  G --> I[Earlier interval stays open]

Where the vendor pages disagree

Every page below was read on 2026-08-20.

Tenant check

Two reads answer one question: does a policy carrying the Teams call logs location exist in this tenant, and from when. Microsoft prescribes the value User:MicrosoftTeamsCallLog for that location.

# Security and Compliance PowerShell. Every command below is a read.
Connect-IPPSSession -UserPrincipalName admin@contoso.onmicrosoft.com

# 1. List every app retention compliance policy.
Get-AppRetentionCompliancePolicy | Format-Table Name,GUID

# 2. Read one policy in full, looking for User:MicrosoftTeamsCallLog.
#    Format-List * is deliberate. The reference documents no property
#    name carrying the location, so read the whole object.
Get-AppRetentionCompliancePolicy -Identity "PolicyName" | Format-List *

# 3. Optional, still a read. Distribution status.
Get-AppRetentionCompliancePolicy -Identity "PolicyName" -DistributionDetail | Format-List Name,DistributionResults

Disconnect-ExchangeOnline -Confirm:$false

Where no policy carries that value, none exists, and every record created since the changeover sits under the indefinite default. Where one does, the date it became active is the boundary, because it covers only call logs created after that point. The same listing shows whether the old chat policy is still enabled.

The data lifecycle management guidance names the least-privileged role for this: "For a read-only role, use View-Only Retention Management." Granting its read-write counterpart to run a read is a finding of its own.

Limitations

The check proves a policy object exists and what location value it carries. It does not prove distribution succeeded, which the third command reads, and it does not prove one call record was ever deleted.

Absence is not by itself a compliance failure. The default is indefinite retention and deletion is the only action available here, so a tenant with no policy is over-retaining. Whether that matters depends on the organisation's own schedule and its basis for keeping telephony metadata.

Microsoft publishes no day for the changeover, only the phrase late April 2026, so this note states no day count. Out of scope: the PSTN and Direct Routing records in the Teams admin center, and meeting recordings and transcripts, which the primary source assigns to OneDrive, SharePoint or Microsoft 365 Group locations. No page read covered the sovereign clouds or a licence specific to call logs.

The PowerShell-only constraint was on the primary page on 2026-08-20. Re-read it before planning a change around it.

Act now

Decision: Act now, and the action is the read rather than the write. The default has been live since late April 2026 and each further day widens an interval no later policy can cover, so there is nothing to schedule and no signal to wait for. The write that follows is a separate decision and usually belongs in the next change window, because the duration has to match a published schedule.

Changes that pass without an error are the ones worth tracking on a schedule, which is what the Microsoft 365 management service is for.