Official documentation checked October 14, 2026.
If Copilot chats remain visible after a retention policy is created, do not immediately shorten the retention period or delete and recreate the policy. First distinguish policy coverage, deployment status, retention versus deletion, and what the user interface shows. This guide concerns organizational Microsoft 365 Copilot interaction data, not personal-account chat history.
1. Check the actual Copilot retention location
New Microsoft Purview retention policies support Microsoft Copilot experiences as a location, separate from ordinary Exchange email and Teams chats. Do not look for a “Copilot interactions” checkbox nested under Exchange email. The fact that compliance copies use Exchange storage does not make the Exchange email location equivalent to the Copilot location.
Older policies used Teams chats and Copilot interactions. Microsoft says those policies remain supported, although they cannot be edited once the tenant supports the separate locations; new policies must use the new locations. Users did not have to use Teams for that older combined policy to cover Copilot. Check the existing policy before replacing it. See the retention overview.
Record whether the problem concerns preserving evidence or deleting expired data. A retain-only policy is not a command to hide every old chat from the app.
2. Verify policy settings and the affected users
In the Microsoft Purview portal, open Solutions > Data Lifecycle Management > Policies > Retention policies. Review the existing policy’s location, included and excluded users, action, and duration. For a new approved policy, select New retention policy, choose a static or previously configured adaptive scope, and select the appropriate Copilot location.
For a static scope, inspect explicit inclusions and exclusions. For an adaptive scope, verify that the affected user’s attributes meet the scope criteria. Keep the administrative-unit setting at the supported default for this policy workflow. Select retain-only, retain-then-delete, or delete-only according to the organization’s approved retention requirement, then review and save. Follow Microsoft’s current configuration instructions, including migration guidance for older combined policies.
Do not interpret an ExchangeLocation value as a required literal CopilotInteractions marker. That was not a valid verification method. If using PowerShell, use the documented policy family and application settings for that specific policy type; do not paste an unrelated migration command into production.
3. Separate deployment time from backend deletion
Microsoft documents that a submitted retention policy can take up to seven days to apply. After deployment, expiration and permanent deletion still involve background processing; neither a new chat nor an old chat is guaranteed to be processed immediately.
Copilot compliance copies are held in hidden Exchange mailbox storage, not a user-accessible Outlook folder. The retention timer normally runs over a period of days, and eligible items pass through hidden hold storage before permanent deletion. Other applicable retention requirements or legal holds can prevent deletion. A delay in the visible chat history therefore does not, by itself, prove policy failure.
Check deployment status, the item’s age, the configured action, and applicable holds before escalating. Do not remove a hold or shorten retention to force a test result. Microsoft’s Copilot retention lifecycle explains the processing stages and why visible history is not a reliable compliance test.
4. Verify with eDiscovery and preserve a useful escalation record
Ask an authorized compliance investigator to use eDiscovery to locate a controlled test interaction for the affected user. Microsoft’s Copilot search guidance covers searching stored interaction data. Finding an item proves that a searchable copy exists; it does not alone establish which of several policies retained it. Likewise, an empty search requires checking the custodian, query, permissions, and supported data coverage.
Keep the test user’s identity, interaction timestamp, policy name and type, scope evidence, deployment status, and search criteria in the case record. Use non-sensitive test text and avoid destructive purge commands. If behavior remains inconsistent with the documented lifecycle, provide that evidence to Microsoft support through the organization’s administrator. This separates a genuine coverage issue from normal processing delay or a mistaken expectation about the chat interface.