Dataverse Audit After Purview: Where Do Old and New Field Values Live?

A security analyst reports that the alert which fired when someone changed a bank account field on a supplier record has gone quiet, and internal audit’s Purview search for field changes now returns who, when and which table, but no old or new value. The rule is not broken; the data it read is gone from Purview, by Microsoft’s design. This guide sets out where the field-level record lives now, how long Dataverse keeps it, what each store can give an auditor, and which checks to re-point, with each Microsoft fact cited to its own Microsoft Learn page. It describes how Dataverse and Purview store and keep audit data; whether a given store or retention period is enough for a regulator or examiner is a decision for your compliance function, not for this guide.

If a rule, report or pipeline stopped seeing old and new values some time after May 2026, this is the change behind it. Microsoft’s Important changes (deprecations) coming in Power Platform page, updated October 6, 2026, states: “Starting in May 2026, Dataverse will no longer include before-and-after field change values in the audit events that are sent to Microsoft Purview.” The same page states: “Audit events will continue to flow to Purview; however, the detailed field-level value changes will be excluded.”

What Purview keeps is the metadata. Microsoft’s Important changes (deprecations) coming in Power Platform page states: “Purview continues receiving audit event metadata (such as who made changes, the date of the changes, and the tables affected), but field-level value changes will no longer be included.” The same page states Microsoft’s reason: “Removing detailed field-level values from Purview-bound audit events reduces the risk of exposing sensitive business or personal information through downstream monitoring or analytics systems.”

Purview activity logging is a separate path from those audit events, and Microsoft describes it the same way. Microsoft’s View Microsoft Dataverse and model-driven app activity logs in Microsoft Purview page, updated July 14, 2026, states: “The details of each column’s before-and-after values for CRUD activites are not sent to Purview activity logging to prevent data leaks.” The same page states that “Column-level secured fields are sent to Purview activity logging with an asterisk”.

Microsoft’s Important changes (deprecations) coming in Power Platform page states: “If you have existing monitoring, alerting, or reporting solutions that depend on before-and-after field change values within Purview audit events, those solutions will stop working once this deprecation takes effect.” The examples that page gives are these:

• Rules that compare old and new values to detect anomalies.
• Data pipelines that analyze changes at the field level.
• Custom compliance checks that run in Purview.

Not every estate is touched. Microsoft’s Important changes (deprecations) coming in Power Platform page states: “No changes are required if your solution uses Dataverse audit logs as the source of truth.”

This guide recommends one step before any fix: list every rule, report, pipeline and check that read old or new values from Purview, with its owner and what it was meant to catch. That list is the scope of the work, and it is the document internal audit will ask for first.

When an examiner asks for the prior value of a changed field, the answer now comes from one store and not the other. Microsoft’s Important changes (deprecations) coming in Power Platform page states: “Dataverse continues to store and expose before-and-after field changes through its native audit APIs and tables.” Microsoft’s Retrieve the history of audited data changes page states: “Auditing events are stored in the Auditing (Audit) table.” The same page states: “The audit table is read-only.”

Not every edit leaves a value behind. Microsoft’s Manage Dataverse auditing page states: “Audit logs for updates are created when a new value is different from the old value of a column.”

For code, the Retrieve the history of audited data changes page on Microsoft Learn documents the RetrieveRecordChangeHistory message, which retrieves all audited data changes for a specific record, and the AttributeAuditDetail type, which gives access to the old and new values; RetrieveAuditDetails returns the detail of a single audit record.

Who can read the history is set by privilege. Microsoft’s Manage Dataverse auditing page states: “Users need the View Audit History privilege to see the Audit History of a record.” The same page states: “Users need the View Audit Summary privilege to see the Audit Summary view.” It also states: “Audit logs might show up with a delay in the Audit History tab of a record and in the Audit Summary view.”

Purview keeps its metadata on its own clock, and as read in October 2026 Microsoft Learn sets it out this way. Microsoft’s Learn about auditing solutions in Microsoft Purview page states that “In Audit (Standard), the system retains records for 180 days”. For activities with no specific policy, Microsoft’s Manage audit log retention policies page states: “Audit records for all other activities are retained for 180 days by default or you can change the retention to a different duration using a custom retention policy.” That page ties retention longer than 180 days, up to 1 year, and retention for 10 years to the licenses held by the user who generates the audit record. Microsoft’s Learn about auditing solutions in Microsoft Purview page also states: “Audit records generated by non-user entities (such as service principal actions, system events, and application activities) are retained for a fixed period of one year.”

This guide’s planning view of the two stores follows. It is drawn from Microsoft’s Important changes (deprecations) coming in Power Platform, Retrieve the history of audited data changes, Manage Dataverse auditing and View Microsoft Dataverse and model-driven app activity logs in Microsoft Purview pages, and it is a summary for planning, not a Microsoft table:

• Purview now returns who made a change, when, and which tables were affected, with no old or new value, and keeps it on Purview’s own retention clock.
• The Dataverse audit table returns the old and new value of each audited change, through a record’s Audit History, the Audit Summary view or the audit APIs, and keeps each record for the retention period stamped on it.
• Reading Purview’s records needs the Audit Logs or View-Only Audit Logs role in Purview; reading Dataverse history needs the View Audit History or View Audit Summary privilege.

This guide recommends writing down, for each regulated app, which store answers the prior-value question, and who holds the privilege to read it.

An examiner asks for the prior value of a field changed some time ago, and whether it still exists depends on a setting that can be chosen once and never read again. Microsoft’s Manage Dataverse auditing page states: “When you set the audit retention period to Forever, the system doesn’t delete logs.” The same page states: “When you set the audit retention period to any other value, the system continuously deletes logs starting at the time an audit record exceeds the time defined in the retention policy.”

A change to the setting does not reach back on its own. Microsoft’s Manage Dataverse auditing page states: “Each audit log is stamped with the currently active retention period.” The same page states: “Changing the retention period here doesn’t change the retention period for already existing records.” It then points to a second route: “Use the Security page auditing option to set the retention policy.” And of that option it states: “This option provides the flexibility to apply the retention policy to existing logs.” So a changed retention period reaches records written after the change, and the Security page option is the route Microsoft documents for applying a policy to existing logs.

The setting is not available everywhere. Microsoft’s Manage Dataverse auditing page states: “The audit retention period isn’t available for Dynamics 365 Customer Engagement (on-premises).”

Deletion follows Dataverse’s own rules. Microsoft’s Delete audit data page states: “You can’t directly delete records in the Auditing (Audit) table.” The same page states that “Dataverse automatically creates partitions every quarter” and that “The current (active) partition and the audit records in it can’t be deleted using this request or any other.” Once history is gone, it is gone: Microsoft’s Manage Dataverse auditing page states: “When you delete audit logs, you can’t view the audit history for the period covered by that audit log.”

Long term retention is not the way out. Microsoft’s Dataverse long term data retention overview page states: “Currently, audit tables and elastic tables aren’t supported for long term retention.” Keeping audit history is a matter of the audit retention value itself, not of moving old records to a retained store.

Keeping everything has a cost in storage. Microsoft’s Manage Dataverse auditing page states: “Dataverse stores audit logs and they consume log storage capacity.” Microsoft’s Dataverse capacity-based storage details page states: “Log entitlement is provided separately for Dataverse only.”

This guide recommends reading the value set in each environment rather than assuming a default. Record each environment’s audit retention value, where it was set and when it last changed, and let the compliance function decide the period, never the storage budget.

A fix tested in a UAT copy of a regulated app left no trace in Purview even before the May 2026 change. Microsoft’s Manage Dataverse auditing page states: “User access or activity logging is sent to Purview for production environments only.” Microsoft’s Power Platform activity logs and auditing in Microsoft Purview page states: “Microsoft Purview auditing solutions capture user activity logs only for production environments.” That page also says to turn on the Enable SAS Logging in Purview setting in the Power Platform admin center for each production environment whose logs you want to view in Purview.

The Dataverse audit table records changes, not reads. Microsoft’s Manage Dataverse auditing page states: “Furthermore, auditing doesn’t support retrieve operations or export operations.” Who opened or exported a record is a different question from what changed, and the audit table does not answer it.

This guide recommends listing every environment that holds regulated data, including test and UAT copies, and noting beside each one which store, if any, records its changes.

Each check on your list needs a new source, and Microsoft names it. Microsoft’s Important changes (deprecations) coming in Power Platform page states: “Update your monitoring or downstream workflows to retrieve detailed field-level audit information directly from Dataverse, not from Purview.” Microsoft’s Manage Dataverse auditing page directs readers to the Web API or the SDK for .NET to retrieve audit data from an environment, and it states: “Exporting audit logs isn’t currently supported.”

For each broken check, decide one of two paths. Either the check reads the Dataverse audit table through the API, using the messages documented on Microsoft’s Retrieve the history of audited data changes page, or it becomes a control that runs on the Dataverse side. Where a SIEM, a log archive or a monitoring tool used to read old and new values from Purview, treat it as one more consumer on the list: it needs the Dataverse audit data by a route you design and test, and this guide does not describe any product’s behavior. Test each re-pointed check on a real changed value before retiring the Purview version, and keep the evidence of that test with the check’s record.

Two neighboring questions have their own answers. If your evidence plan also covers Microsoft Fabric, Purview’s evidence for Fabric is a separate plan, set out in Purview audit evidence for Microsoft Fabric. The retention of Microsoft Entra sign-in and audit logs is a separate question as well, and this guide does not cover it.

If your estate matches one of the cases in the following list, this change asks little of you or this guide does not go far enough. The cases rest on Microsoft’s Important changes (deprecations) coming in Power Platform and Manage Dataverse auditing pages as read in October 2026:

• If your monitoring already reads the Dataverse audit table, Microsoft’s change page says no change is required.
• If auditing was never turned on for the table and column, there are no old and new values in either store, because Dataverse writes an update log only where auditing is on and the new value differs from the old.
• If the environment runs Dynamics 365 Customer Engagement (on-premises), the audit retention period isn’t available.
• Microsoft’s pages read for this guide do not say whether this change, the activity-logging path or the Enable SAS Logging in Purview setting behaves the same way in GCC, GCC High or DoD, so this guide does not describe those clouds.
• Whether field-level change history is a record your regulator requires, and for how long, is a decision for your compliance function; this guide does not make it.
• If the question is approval evidence and human override in automated approval workflows, that belongs to an approvals control framework, a separate question from this one.

If you bring this to i3solutions, the work is a design and readiness project with your team: inventory the checks that read old and new values from Purview, design their re-pointing to the Dataverse audit table, document each environment’s audit retention value and where it was set, and hand the design to the team that runs it. i3solutions workflow automation builds use standard and premium Power Platform connectors, custom API connectors published through Azure API Management, and hub-and-spoke approval patterns built on Dataverse tables or SharePoint lists. i3solutions builds client workflow automation on Power Automate cloud flows, Power Automate desktop flows for RPA, and Azure Logic Apps in both the Standard and Consumption tiers. Those are the mechanisms a re-pointed check can run on.

Our teams maintain dedicated compliance specialists who understand CMMC, HIPAA, SOC 2, and financial services regulations within Microsoft environments, providing audit trail documentation and access control frameworks that reduce audit preparation time by 60%. i3solutions designs, builds, documents and supports what it built; running a SIEM or watching the audit logs day to day stays with your security operations team, and the retention period and the record of truth are decisions for your compliance function. This page claims no prior client work on this Microsoft change.

i3solutions runs client Power Platform work on a multi-tenant Center of Excellence model with separate Dev, Test, UAT, and Production environments promoted through managed solutions. i3solutions runs a governed Power Platform for a federal defense agency supporting roughly 10,000 personnel across about 180 locations, which works because it is governed, not despite it. All i3solutions Power Automate developers and consultants are U.S.-based.

For the wider practice, see Power Platform development services.