Long-term data retention

What it does

A retention policy moves rows matching a criterion out of the live application state into the Dataverse long-term retention store. The data never leaves Dataverse and never leaves your security model — it becomes read-only, compressed, and reachable through Advanced Find, cloud flows and the OData APIs.

Key facts

The environment holding the retention policy must be a Managed Environment. Without that, you can still create policies but they stay disabled.
Retention is one-way. Once a row is retained it can't be returned to the live state, ever.
Standard tables (excluding system tables), custom tables, and their attachments and images can be retained. Audit tables and elastic tables aren't supported.
Enabling retention on a parent root table also enables it for child tables and their attachments and images — but not when retention is enabled through a solution import, where child tables have to be done separately.
Existing delete cascade behaviours and plug-ins fire when a policy runs, and you can register custom plug-ins on the retain action.
Policy runs make API calls that count against your tenant's Power Platform request allocation.
Capacity reports show the retained data as a second entry per table, named Table-Retained, alongside the live table.
Retained data typically compresses by around 50% on average against its live footprint, so database consumption drops but doesn't disappear. Microsoft is explicit that the actual figure varies with the data.
File and image attachments get effectively no capacity saving from retention. Only the database side compresses.
A policy run takes 72 to 96 hours, plus roughly another 24 before capacity reports update. Production reports can take days to a week to show the full saving; non-production up to two weeks.
Log capacity reports for retention aren't currently available.
Retention policies are solution-aware via the Data Life Cycle Config component, the same one bulk deletion jobs use. Definitions are portable; retained data isn't.

When to use / skip

Retention is the right answer when a client has to keep records for a statutory period but nobody needs to edit them — closed cases, completed orders, historic activity, anything where "we can't delete it and we can't use it" is the honest description. It is not a storage optimisation trick: the saving is real but partial, it takes days to appear, and it costs you API requests and a Managed Environment. If the data has any chance of coming back into an active process, don't retain it, because there's no route back. And if the problem is file attachments rather than rows, retention won't help you at all.

Configuration decisions

Which tables get a policy, and the criterion that defines "inactive" for each — usually a status plus an age, agreed with the business rather than inferred.
Whether policies are managed as solution components through the ALM pipeline or configured directly in production.
What the access route to retained data is: Advanced Find for occasional lookups, a flow or a custom screen over the OData API for anything routine.
Whether custom plug-ins on the retain action are needed to write an archive reference, notify a downstream system, or stamp the row.
Where retention stops and deletion starts — the third stage of the lifecycle still has to be designed.

Gotchas

The Managed Environment requirement catches Dynamics 365 clients who assumed their licences already covered it. Check before you promise the feature.
Enabling retention via solution import doesn't enable the child tables. You'll retain the parent and leave the children live, which is the worst of both.
Because delete cascades and plug-ins execute during a run, a retention policy on a heavily-related table generates a substantial background workload. It isn't a quiet housekeeping job.
The 72-to-96-hour run plus reporting lag means nobody sees a result on the day. Set expectations before the first run or you'll spend a week fielding "did it work?".
Users need to be told that retained rows won't appear in normal views. Advanced Find against retained data is a different query, and that's a training item.

Consultant notes

Frame this to the client as a compliance capability that happens to save capacity, not as a capacity tool. That's the honest framing and it survives the first run's disappointing numbers.
Get legal or compliance to state the retention period per record type in writing before you build anything. Consultants guessing at statutory periods is how this goes wrong.
Don't quote a compression percentage as a commitment. Around 50% on average is what Microsoft documents, with the caveat that it varies — and file data gets none.
Audit data being out of scope matters: clients who want to shrink log capacity need audit deletion or a Synapse-based archive, not retention.

Worth another look if audit or elastic tables become supported, or if retained file capacity ever starts compressing.