Dataverse data archiving: design the retrieval before the retention policy

Most archiving projects I see start with a capacity warning. The better starting point is a person: an auditor or a support officer who needs a five-year-old record next Tuesday. How will they find it, and what will they still be able to do with it?

That answer tells you whether a record should stay active, move into long-term retention, or be deleted.

What long-term retention actually is

• A read-only store inside Dataverse for inactive business data. Retained records cannot be moved back into the active application.
• It needs a Managed Environment. Without it, retention policies are disabled.
• Standard and custom tables are eligible. Audit and elastic tables are excluded.
• Compression reduces database capacity. Attachments and images do not give a similar saving on file capacity.

So before proposing anything, check which storage is really under pressure: database, file or log. The fix is different for each.

Age is not the same as inactive

Take a service organisation. Resolved cases older than an agreed period look like good candidates. But a closed case that can still be reopened is a different thing. Age helps you find candidates. The business lifecycle decides whether they are truly finished.

Retrieval has real limits

Microsoft documents retrieval through model-driven app filters, Power Automate and supported APIs. The standard path is deliberately constrained:

• five concurrent users;
• 100 queries per environment per day;
• single-table queries, no joins and no aggregation.

Users also need organisation-scope read privileges on the table. If your security model is built on business units, do not assume it gives the archive experience you expect. Test it with real people. For analysis across live and retained data, Microsoft Fabric is another option, with its own architecture and access decisions.

A simple retrieval query looks like this — ten retained accounts, two columns, read-only:

<fetch datasource="retained" top="10">
  <entity name="account">
    <attribute name="accountid" />
    <attribute name="name" />
  </entity>
</fetch>

It is an example of getting data back, not the rule for archiving. Real investigations need the identifiers and filters auditors actually use. Test attachment retrieval separately.

Setting up a first policy

1. Agree eligibility with the data owner: parent table, business status, cutoff date and exclusions, including records under investigation.
2. Prepare a sandbox. Confirm Managed Environment and licensing. In Power Apps, open the table properties, expand Advanced options and enable long-term retention.
3. Build a dedicated view for the criteria. Check a small sample and the edge cases with the business.
4. Create the policy as a Power Platform administrator: Retention policies, root table, tested view, schedule. Start with a one-time pilot.
5. Prove it. Check run status, retained records, related data and retrieval by an authorised user. Allow for processing delays before judging capacity.

Keep lifecycle settings with the solution

Mark Carrington's June 2026 article on bulk deletion makes a good point: put lifecycle jobs in solutions so they are not forgotten between environments. Retention policy definitions are solution-aware too. Moving the definition does not move any retained records, so check table enablement in every target environment, including related tables.

I make a successful retrieval test a condition of approval. If a business user cannot find a historical record, explain its relationships and get the evidence, the storage saving has just become a support problem.

Start with one table

Write a one-page decision record for a single table: what makes a row inactive, why it must be kept, who needs it, how it is retrieved and when it is finally disposed of. Compare retention, deletion and external archiving against that page, then pilot a small cohort in a sandbox.