Dataverse Audit Logs to Purview Now Redact Sensitive Fields. Your Incident Response Runbook Still Points There.

Compliance analyst reviewing a Dataverse audit log dashboard with some sensitive fields redacted before reaching Microsoft Purview

A security engineer investigating a compliance escalation pulls up Microsoft Purview’s unified audit log and searches for changes to a customer’s tax identification field in a Dynamics 365 Finance environment. The Dataverse audit configuration has been correctly enabled for years: environment-level auditing is on, the table is audited, the column is audited, and “Read logs” has been flowing activity to Purview since the tenant went live. Yet the search results show the record was updated, by whom, and when, but the actual before-and-after values for that field come back empty. Nothing is broken. Since June 26, 2026, Dataverse audit logs to Purview have deliberately worked this way for a defined set of sensitive columns, and most compliance and security teams have not yet updated their runbooks to account for it.

The feature responsible is a narrowly scoped but consequential change: Dataverse now strips certain categories of sensitive data, specifically financial information, health data, and personally identifiable information, out of audit events before they are transmitted to Purview’s activity logging pipeline. The values still exist. They are simply no longer making the trip to Purview, and that distinction has real operational consequences for anyone who built incident response, eDiscovery, or SIEM processes on the assumption that Purview’s audit log search was the complete picture.

What Actually Changed in Dataverse Audit Logs to Purview

Dataverse auditing has always captured create and update events at the column level, including the before-and-after value of every audited field, when environment, table, and column auditing are all enabled through the hierarchy Microsoft documents under Security, Compliance, and Auditing in the Power Platform admin center. Historically, if the environment’s “Read logs” setting was turned on, that entire audit record, field values and all, flowed to Purview’s unified audit log and became searchable at compliance.microsoft.com/auditlogsearch by anyone with the appropriate compliance role.

That behavior is what changed with general availability on June 26, 2026. Microsoft’s own release notes describe the mechanism plainly: create and update events, including a column’s before-and-after values, are still captured in Dataverse’s native audit store exactly as before. What changes is the copy sent onward to Purview. Financial data, health and medical information, and personally identifiable information are removed from that outbound payload before it leaves Dataverse. A change to a customer’s shipping address or a sales order’s discount percentage will still show full detail in Purview. A change to a national ID number, a diagnosis code stored in a custom health field, or a salary figure will not, even though every one of those changes is still fully visible inside Dataverse itself.

The rationale is straightforward: the unified audit log has a materially larger blast radius than Dataverse’s native audit history. Native audit history requires a Dataverse security role scoped to a single environment. The Purview unified audit log is a tenant-wide surface, reachable through eDiscovery cases and exportable by compliance investigators who may hold no Dynamics 365 role at all, retained under Microsoft 365 audit policy rather than Dataverse’s own retention settings. Sending unredacted salary or health data into that surface multiplied the number of people who could, deliberately or accidentally, end up looking at it.

Two Purview Pipelines That Behave Differently

Here is where the practical confusion tends to start. Dataverse actually feeds Purview through two distinct mechanisms, and they were never symmetrical even before this change. Classic Dataverse auditing, the one most organizations configured years ago through the environment’s “Log access” and “Read logs” toggles, is the pipeline this new redaction applies to. It is also the pipeline that historically sent complete field-level detail.

Separately, Dataverse’s comprehensive activity logging, the broader mechanism that captures nearly every SDK message an environment processes, including bulk exports, Advanced Find queries, and support engineer actions, has never sent column-level before-and-after values to Purview at all. Microsoft’s own documentation on comprehensive auditing states that column-level secured field values are sent to Purview as an asterisk rather than the underlying data, and that detailed field-level changes are withheld entirely from that pipeline specifically to prevent data leaks. That restriction predates the June 2026 change and applies regardless of whether a field touches financial, health, or PII data.

The practical upshot is that an organization relying primarily on comprehensive activity logging for its Purview visibility was already missing granular field values, and nothing changes for them. An organization that built its compliance program around classic Dataverse auditing with “Read logs” enabled, treating Purview’s audit log search as a faithful mirror of Dataverse’s own audit history, just lost a slice of that fidelity for exactly the categories of data most likely to matter in a regulatory inquiry.

Abstract illustration of a data grid with selectively redacted cells representing sensitive data masking

Where the Complete Record Still Lives

Nothing about this change reduces what Dataverse itself retains. The full before-and-after values for every audited column, sensitive or not, remain in Dataverse’s native audit store under whatever retention policy the environment has configured, which can run from a fixed number of days out to indefinite retention on production environments that support it. That data is accessible through the Power Platform admin center’s auditing summary view, through the classic audit history UI on individual records, and programmatically through the Dataverse Web API using the Audit entity or the RetrieveRecordChangeHistory message.

This is the detail worth building process around: if an investigation genuinely needs the value of a redacted sensitive field, the answer is not to escalate a Purview support ticket, it is to pivot the investigation to query Dataverse directly, using a role that has legitimate access to the Audit entity in that specific environment. That is a narrower, more auditable path than a tenant-wide Purview search, which is precisely the point of the change, but it means any documented incident response procedure that says “search Purview” as the first and only step now needs a second step for sensitive-field cases.

What to Check in Your Environment

Start by confirming which environments actually have “Read logs” enabled at the environment level, since that is the specific setting this change affects. Environments relying solely on comprehensive activity logging were never sending field-level detail to Purview and require no adjustment on this front, though it is still worth confirming which pipeline your compliance team believes it is querying, because in practice that assumption is not always accurate.

Next, inventory any downstream system that consumes Purview’s unified audit log for Dataverse activity: SIEM ingestion pipelines, Sentinel analytics rules built on audit log content, scheduled compliance reports, or custom Power BI dashboards pulling from the audit log search API. Any of these that parse or alert on specific before-and-after field values for financial, health, or PII columns will now see blank or null values where they previously saw data, which can silently break a detection rule that was matching on a specific value pattern rather than simply on the fact that a change occurred.

It is worth testing this directly rather than taking the documentation’s word for it, since Microsoft does not fully specify the exact classification logic used to flag a column as financial, health, or PII data. In a sandbox environment, make a controlled change to a column you believe falls into one of those categories, then compare what appears in Purview’s audit log search against what native Dataverse audit history shows for the same event, and repeat the test with a column outside those categories. The gap between documentation and observed behavior is where governance teams tend to get surprised months later.

A Compliance Improvement, Not a Complete DLP Control

It is tempting to read this feature as Microsoft having solved sensitive-data exposure in audit logging, and it has not, at least not entirely. It reduces exposure specifically on the path from Dataverse to Purview’s unified audit log for three defined data categories. It does nothing about sensitive data that lives in Dataverse’s own audit store, in exports, in Dataflows destinations, in Power BI datasets built on top of audited tables, or in any custom integration that pulls audit data directly from the Web API rather than through Purview. Organizations that treat this as a checkbox for their broader data loss prevention obligations under regulations like HIPAA or a state privacy law are conflating a narrow platform default with a program-level control, and an auditor will draw that distinction even if the platform release notes do not spell it out.

The more accurate framing is that Microsoft closed one specific, previously overlooked exposure path, and organizations now need to confirm their own audit consumption patterns still work correctly on the other side of that change. For teams running Dynamics 365 Finance and Operations or Customer Engagement with meaningful volumes of regulated data, that is a worthwhile few hours of validation, not a reason to assume the compliance posture improved on its own without anyone checking. Routeget Technologies has walked several clients through exactly this kind of audit configuration review after a platform-level change shifted what their existing monitoring actually captured, and the pattern is consistent: the environments that catch these gaps early are the ones that treat platform release notes as an input to a review, not as the review itself.

#DataverseAudit #MicrosoftPurview #PowerPlatformGovernance #DataLossPrevention #ComplianceMonitoring #EnterpriseSecurity

Configuring Dynamics 365 Email Sensitivity Labels Without Losing Copilot

IT security and compliance professional reviewing an email data classification and encryption dashboard

A Customer Service administrator at a regulated financial services firm spent most of Q1 rolling out Microsoft Purview sensitivity labels across the organization’s email traffic, a project driven by a compliance mandate that had nothing to do with the contact center. Once Dynamics 365 email sensitivity labels went live in the Customer Service workspace, the security team considered the job done. Three weeks later, a supervisor noticed that case summaries were quietly missing for a cluster of escalated tickets, and Copilot’s intent detection wasn’t firing on a subset of inbound email at all. The two projects, security and AI, had never been evaluated together, and nobody had checked whether the feature that satisfied the compliance mandate was compatible with the feature the contact center had spent the prior year building its workflows around.

That collision is becoming common enough to plan for directly. Data sensitivity labels for email reached general availability in Dynamics 365 Customer Service on May 1, 2026, giving service representatives a native way to classify and protect outbound and inbound messages using labels defined centrally in Microsoft Purview. It is a genuinely useful capability, and for regulated industries it is close to mandatory. But it was shipped as a security feature, evaluated by security teams, and its interaction with Copilot-driven case automation is easy to miss until an agent asks why a summary never generated.

What Actually Ships With the Feature

The capability itself is narrow and well-scoped: agents get a Sensitivity Label dropdown in the command bar, available both when reading an inbox item and when composing or replying to an email, inside the Customer Service workspace and Contact Center apps. Labels are not created in Dynamics 365 at all. They are authored in the Microsoft Purview compliance portal, under Information Protection, where an administrator defines the label’s name, priority, scope, and, critically, its protection settings, including whether it carries encryption, a Do Not Forward restriction, or a visual marking like a watermark or header. Once that label policy is published tenant-wide, it becomes available inside Dynamics 365 without any additional publishing step on the Dataverse side.

What surprises a lot of technical teams is how much of the actual behavior is inherited from Purview rather than configured in Dynamics 365. A label that carries an encryption policy behaves identically whether it was applied from Outlook, from Word, or from a Customer Service email form: the message becomes a protected, rights-managed object the moment the label is applied, not a cosmetic tag on a Dataverse record.

Configuring Dynamics 365 Email Sensitivity Labels: The Two-Step Setup

The rollout has two distinct halves, and skipping the prerequisites is the most common reason a pilot stalls. Before anything happens inside Dynamics 365, the environment needs an email server profile configured for Server-to-Server Authentication against the same tenant’s Exchange Online, and server-side synchronization for email has to already be running. Neither of those is new infrastructure specific to this feature, but plenty of sandbox and dev environments never had them fully wired up, since basic email testing doesn’t require them.

With that in place, enabling the feature itself is a single toggle: in the Power Platform admin center, under the target environment’s Settings, expand Email, open Email Settings, and switch on “Enable data sensitivity labels for emails.” The second half of the work happens in Power Apps rather than the admin center. Inside the relevant solution, add the Email table’s main form to the solution if it isn’t already there, open the form in the designer, locate the “Sensitivity label” column, and drag it onto the canvas. On its own that column just stores a value, so the practical step is adding the “Email sensitivity label control” component to the same field and configuring it, then saving and publishing the form. Skip that control and the column exists on the record but agents never see anything to interact with.

One detail worth flagging to the security team directly: the Entra ID identity associated with the mailbox needs its own permissions in Microsoft Purview to apply the labels that are relevant to that queue. This is a common gap in shared-mailbox and queue-based routing setups, where the mailbox identity was provisioned years ago for basic send/receive and never touched again.

Solution architect configuring email sensitivity label settings in a Dynamics 365 environment

How Enforcement Actually Behaves in Practice

Once labels are live, the enforcement rules mirror what a user would expect from Outlook, and that consistency is deliberate. A label like Do Not Forward or Do Not Reply restricts the corresponding action for recipients inside the organization, and an agent cannot manually downgrade a message to a less restrictive label than the one already applied, so a “Confidential” thread can’t be quietly relabeled “General” to make it easier to forward externally. Replies and forwards inherit the label of the message being responded to by default, which is the behavior most compliance teams actually want, since it removes the judgment call from the agent in the moment they’re least likely to think about it. Attachments carry their own labels independently, and when an attachment’s label conflicts with the email’s label, the interface surfaces which one takes precedence rather than silently picking one.

Where this gets operationally interesting is auto-labeling. Purview supports content-based auto-labeling, where a label gets applied automatically based on what the message contains, and that setting lives entirely in Purview, invisible from the Dynamics 365 side. A queue that starts seeing a spike in encrypted, auto-labeled mail didn’t necessarily have a policy change made against it directly. Somewhere upstream, a Purview label’s auto-apply conditions matched more content than before.

The Gap Nobody Tests For: Encrypted Mail and Copilot

This is the part of the rollout that deserves its own test plan rather than a footnote. When a label applies encryption protection, Dataverse does not decrypt or store the message content. The email still appears in the case timeline, so an agent knows the correspondence exists, but the body is not readable inside the application at all. Agents are redirected to Outlook on the web to open and decrypt the message there.

That gap propagates directly into every Copilot capability that depends on reading email content. Case summarization skips encrypted messages entirely, meaning a case summary generated near the end of a long thread may be missing the specific email that actually contains the customer’s core complaint, if that thread’s most detailed message happened to carry a Confidential-and-Encrypted label. Case enrichment, intent detection, and any Copilot workflow built around analyzing inbound email content behave the same way: they simply do not see encrypted mail, and there is no fallback summarization or partial analysis. From the AI feature’s perspective, the message is invisible, not redacted.

For a technical team that built intent-based routing or auto-summarization as part of a Copilot rollout, this means the encryption policy decided in a completely separate Purview governance project can silently degrade the reliability of automation the contact center is depending on operationally. Neither team is wrong about their own configuration. The interaction between the two simply isn’t visible from inside either admin surface on its own.

Rolling This Out Without Breaking What Already Works

The practical fix isn’t to avoid sensitivity labels, since for a regulated organization that usually isn’t optional, and blanket-disabling encryption defeats the purpose of the compliance project in the first place. The fix is sequencing the two conversations that normally never happen in the same room. Before a label policy that carries encryption goes anywhere near production mailboxes tied to Customer Service queues, pull a sample of real case threads that currently drive summarization or intent detection, and run them through the label to see which specific messages would become invisible to Copilot under that policy. That test takes an afternoon and reliably surfaces problems that would otherwise take weeks to notice in production, one confused agent at a time.

It’s also worth treating auto-labeling as a change management event even though it technically lives entirely in Purview. Any time compliance adjusts an auto-apply condition on a label with encryption attached, that change has a direct, measurable effect on Copilot coverage in the contact center, and the service delivery team should be in the notification loop for that change, not discovering it through a drop in summarization quality. Finally, agents need to know the Outlook-on-the-web redirect path exists and why it exists, rather than treating an unreadable encrypted email in the case timeline as a bug to escalate. A short addition to onboarding material covers this permanently; a support ticket every time it happens doesn’t.

Routeget has walked several clients through exactly this sequencing problem when a compliance-driven Purview rollout landed on top of an existing Copilot investment in Customer Service, and the fix is almost always coordination rather than reconfiguration. Getting the security and the AI roadmap talking to each other before go-live is considerably cheaper than untangling the symptoms afterward.

#DynamicsCustomerService #DataSensitivityLabels #MicrosoftPurview #CopilotService #EmailSecurity #ComplianceGovernance