Long term data retention for service data

What it does

Dataverse long term retention moves rows you no longer work with out of the live tables and into a read-only retained store inside the same environment. The data stays queryable and stays counted, but it stops loading the application. For a service desk this is how you deal with a decade of closed cases without deleting them.

Key facts

The environment has to be a Managed Environment. Retention policies created in a non-managed environment are disabled and do nothing.
Supported: Dataverse standard tables (excluding system tables), custom tables, and attachments and images on them. Not supported: audit tables and elastic tables.
Enabling retention on a root parent table automatically brings its child tables and their attachments and images along.
Retention is one-way. A retained row cannot be returned to the live application. Plan on that being permanent.
Retained data is immutable and read-only, and is reached through Advanced Find, Power Automate cloud flows, or the Dataverse OData APIs for a custom screen.
Rows compress by roughly 50% on average when retained, so the capacity you consume drops. File and image attachments do not compress and give no capacity saving.
Capacity reports show the live and retained volumes separately — you'll see "Case" and "Case-Retained" as distinct lines.
A policy run takes roughly 72 to 96 hours to complete, and capacity reporting takes another 24 hours or so to catch up.
Policy runs consume API requests against your existing entitlement, same as any other bulk operation.
Retention policies are solution-aware, so they can be added to an unmanaged solution and moved through environments like any other component.
Existing delete cascades and plugins execute during a retention run, and you can write a custom plugin against the retain action.

When to use / skip

Use it when the client has real volume and a real retention obligation — a service desk with eight years of closed cases, a regulator who wants seven of them kept, and a database bill that's growing. Retention answers both halves of that.

Skip it if the environment is small. Under a few hundred thousand cases, the capacity saving won't pay for the design work, and you'll add a store that reporting can't reach for no operational benefit. Also skip it if the client's real problem is that nobody ever closes cases — retention doesn't fix a process problem, it just archives the evidence.

This is a different thing from bulk deletion. Bulk delete removes rows. Retention keeps them, in a place that doesn't slow the app down. Most clients need both, for different data.

Configuration decisions

Which root table drives the policy. For a service desk it's almost always Case, with activities, notes and attachments following as children — but check whether anything you care about hangs off something else.
The retention criterion: closed date, resolution date, or a bespoke flag. Get the business to sign this off in writing, because it can't be undone row by row.
Whether attachments go with the case or are dealt with separately. They dominate storage and don't compress.
Whether the environment becomes a Managed Environment purely for this, and who owns the governance obligations that come with that.
How retained data gets read: Advanced Find for occasional lookups, or a purpose-built flow or screen if the business genuinely needs regular access.
How the policy moves through environments — solution component, or configured directly in production with a documented runbook.

Gotchas

The one-way transition is the one to say out loud, twice. There is no "restore to live" button and nobody expects that until it matters.
Analytics don't follow. Historical Customer Service analytics, dashboards and any warehouse feed built on the live tables will stop seeing retained cases, and the numbers change the month you switch it on.
The 72 to 96 hour run window plus 24 hours of reporting lag means "did it work?" is a question you can't answer for the best part of a week.
Plugins fire during the run. A plugin registered on delete or on the retain action can turn a routine policy run into a very long one, or a failed one.
SLA KPI instances, related activities and notes are child data — if they're not covered, you retain the case and leave the debris behind, which achieves nothing for capacity.
File and image attachments give no compression benefit, so the headline 50% saving won't match what the client sees if their cases are attachment-heavy.

Consultant notes

Get the retention criterion approved by whoever owns the client's records policy, not by the service desk manager. It's a compliance decision wearing a technical hat.
Run the first policy against a narrow slice in a copy of production and time it. The run duration on a real dataset is the number the client will ask about.
Warn the reporting team before, not after. Losing retained cases from a management dashboard on a Monday morning is a bad way to introduce a feature.
Check whether the environment is already a Managed Environment. If it isn't, that conversation has its own cost and its own approvals.
Keep a documented list of what's retained and when the policy runs, so the next person doesn't go looking for missing cases in the live tables.

Worth revisiting if Microsoft adds a route back from retained to live, or extends support to audit tables.