Dataverse Auditing Change: Purview Loses Before-and-After Field Values in 2026

Microsoft has stepped in to close that exposure path. Under AI at Work roadmap ID 576863, Microsoft has launched a governance and compliance change for Microsoft Power Platform that strips customer business data—specifically before-and-after column values—out of Dataverse audit events before those events are forwarded to Microsoft Purview activity logging. While the change reduces the risk of leaking sensitive information into downstream monitoring tools, it also breaks any custom Purview alerts or compliance workflows that previously inspected field-level changes in transit.

Here is a breakdown of what has changed in the Dataverse-to-Purview pipeline, the timeline discrepancy in Microsoft's documentation, and how administrators need to adapt their compliance monitoring architectures.

The Core Change: Metadata Goes to Purview, Field Values Stay in Dataverse​

To understand the update, it helps to separate how Dataverse records changes internally from how it reports activity to Microsoft Purview.

When Dataverse auditing is enabled for an environment, table, and column, the platform tracks create, update, and delete operations on customer records. Whenever a user or automated process modifies a column and the new value differs from the old one, Dataverse records both the prior value and the updated value. In real-world business applications, those columns frequently hold highly regulated information: financial figures, medical and health data, or personally identifiable information (PII).

Previously, when organizations integrated Dataverse with Microsoft Purview activity logging, those before-and-after field change values traveled along with the audit events into the Purview auditing stream. Under Microsoft's updated behavior, customer data is removed before the audit events leave for Purview.

As noted in Microsoft Learn's Power Platform deprecation documentation, audit events still flow to Purview, and Purview continues to receive the surrounding metadata—including which user modified a record, when the modification occurred, and which tables were touched. However, the granular field-level value changes are excluded from the Purview payload. Meanwhile, the complete before-and-after values remain intact inside Dataverse's native audit logs.

Section Summary: Microsoft has decoupled activity metadata from actual record content in the Purview pipeline. Purview still sees who touched what table and when, but the actual data values before and after an edit remain strictly inside Dataverse.

Rollout Timeline and Scope Boundaries​

If you are checking your calendars and wondering when this behavior took effect, Microsoft's official documentation presents two slightly different milestones that administrators should note:

• Deprecation Notice Start Date (May 2026): In Microsoft Learn's list of important changes and deprecations coming to Power Platform, the entry for "Removal of before-and-after field change values in audit events sent to Microsoft Purview" states that Dataverse stops including before-and-after field change values starting in May 2026.
• Roadmap and Release Plan General Availability (June 2026): The Microsoft 365 AI at Work roadmap listing (ID 576863) marks the feature status as "Launched" with a general availability date of June 2026 for Worldwide (Standard Multi-Tenant) cloud instances on the Web platform. Microsoft Learn's 2026 release wave 1 plan further specifies the general availability date as June 26, 2026.

Microsoft's published documentation does not explain the gap between the May 2026 start window in the deprecation notice and the June 26, 2026 general availability date in the release plan. Regardless, for environments running today, the change is live and enforced.

It is also important not to overstate the boundary of this update. According to Microsoft Learn's documentation on managing Dataverse auditing, user access and activity logging are sent to Purview for production environments only. Furthermore, this update does not turn off Purview activity logging for Power Platform, nor does it purge historical or ongoing audit records inside Dataverse itself.

Why It Matters: The Security vs. Observability Trade-Off​

Why did Microsoft sever field-level values from the Purview stream? Based on general industry knowledge of enterprise SIEM (Security Information and Event Management) and compliance architectures, audit logs are a notorious vector for accidental privilege escalation.

Inside Dataverse, access to sensitive columns can be tightly governed using role-based security and column-level security profiles. In fact, Microsoft Learn notes that even previously, when auditing was turned off for a specific column, its before-and-after values were masked with an asterisk (*) when sent to Purview. However, when auditing was turned on for sensitive columns, shipping the raw before-and-after values into Purview meant that downstream compliance analysts, SOC engineers, or external log-ingestion pipelines connected to the Office 365 Management API could potentially read Cleartext PII, patient health updates, or executive compensation changes—even if those personnel had zero permissions to view the records inside the Dynamics 365 or Power Apps environment.

By stripping customer business data before it hits Purview, Microsoft aligns Power Platform with strict data-minimization principles.

What Breaks in Downstream Tooling?​

The flip side of data minimization is reduced observability for teams that built automation around those exact payloads. According to Microsoft Learn's deprecation guidance, any monitoring, alerting, or reporting solution that depends on comparing old and new field values inside Purview audit events will stop functioning once the values are omitted.

For example, if your security team built an anomaly-detection rule in Purview (or in a downstream SIEM ingesting Purview logs) that triggers an alert whenever a vendor's bank routing number column changes from Value A to Value B, or whenever a credit limit column is increased by a specific threshold, that rule will now evaluate empty field deltas. Purview will still log that the table was updated by a specific user, but it will no longer know what the old or new text or numeric values were.

Section Summary: Removing field values protects organizations from leaking PII, financial, or medical records into broad compliance and SIEM pipelines, but it breaks downstream rules that rely on Purview to inspect exact data modifications.

Actionable Guidance: How to Adapt Your Auditing Workflows​

If your organization only uses Purview to track high-level user activity—such as who signed in, which tables were modified, or whether admins changed environment governance policies —no action is required. Similarly, if your compliance workflows already query Dataverse directly as their source of truth, your setup is unaffected.

However, if your compliance or security workflows relied on Purview for field-level change analysis, Microsoft instructs administrators and developers to re-architect those workflows to pull detailed audit data directly from Dataverse. Here is what you need to know when planning that transition, based on Microsoft Learn's Dataverse auditing documentation:

1. Use Native Dataverse Retrieval Paths: Detailed before-and-after values remain accessible within the Dataverse environment via the record-level Audit History tab (requires the View Audit History privilege) and the environment-wide Audit Summary view (requires the View Audit Summary privilege).
2. Programmatic Access via APIs or Azure Synapse Link: Because exporting audit logs directly from the user interface is not currently supported in Dataverse, automated compliance pipelines must retrieve audit history programmatically using the Dataverse Web API or the SDK for.NET. Alternatively, administrators can use Azure Synapse Link for Dataverse to link the audit table and build compliance reports in Power BI.
3. Verify Three-Tier Audit Configuration: To ensure Dataverse itself is capturing the field deltas you need, verify that auditing is turned on at all three required levels:
   • Environment level: In the Power Platform admin center under Manage > Environments > [Environment] > Settings > Audit and logs > Audit settings, ensure Start Auditing is enabled.
   • Table level: In Power Apps (Dataverse > Tables), open the table properties, expand Advanced options, and verify Audit changes to its data is checked.
   • Column level: Under the table's Schema > Columns, open the target column, expand Advanced options, and confirm Enable auditing is selected.
4. Account for Storage and Size Boundaries: When querying Dataverse audit logs directly, keep in mind that audit records are stored in Dataverse log storage rather than standard database storage, which can introduce a slight delay before new entries appear in the Audit History or Audit Summary views. Additionally, large attribute values—such as Email.description or Annotation—are capped at 5 KB (approximately 5,000 characters) in the audit log, with truncated text marked by trailing ellipses (...).

Balancing airtight data privacy with deep security visibility is never simple, especially when low-code platforms handle sensitive enterprise records. By keeping field-level values inside Dataverse and sending only activity metadata to Purview, Microsoft has drawn a much cleaner security boundary—even if it means compliance engineers have a few data pipelines to rewire.