What it does

Dataverse auditing records changes to row data, changes to sharing and security roles, and — separately — user access. It's configured at three levels that all have to line up: environment, table, then column. Audit records live in log storage and are read through Audit History on a record, the Audit Summary view, or the Web API.

Key facts

• Three switches, all required for data change logging: auditing on at the environment, Audit changes to its data on the table, Enable auditing on the column. Miss one and you get nothing.
• Update audit rows are only written when the new value actually differs from the old one.
• What's covered: create, update and delete on rows; changes to a row's sharing privileges; N:N associate and disassociate; changes to security roles; deletion of audit logs themselves.
• What isn't: table and column definition changes, authentication, retrieves and exports. Read and export logging comes from Dataverse activity logging into Microsoft Purview, which needs the environment-level Read logs setting and has its own licensing minimum.
• A set of non-customisable system tables can't be audited at all — ActivityPointer, Annotation, Workflow, Calendar, Service and others, identifiable by CanModifyAuditSettings being false.
• Audit data consumes log capacity, not database capacity, and appears as AuditBase in the per-table breakdown.
• Retention default is Forever. Other options delete continuously once a record passes its age, with a custom maximum of 24,855 days.
• Each audit row is stamped with the retention period that was active when it was written. Changing the retention setting doesn't restamp existing rows — only the Security > Compliance page option applies a policy to existing logs.
• Audit retention isn't available for environments encrypted with a customer-managed key, or for Customer Engagement on-premises.
• Audit deletion runs as an asynchronous background job at roughly 100 million records a day, monitored through the Bulk deletion view.
• Large values such as email descriptions or annotations are capped in the audit record at about 5 KB, marked with a trailing ellipsis.
• There's no export from the Audit Summary view. Pull audit data through the Web API or SDK, or link the Audit table via Azure Synapse Link and report on it in Power BI.

When to use / skip

Turn auditing on somewhere in every regulated implementation, then argue hard about scope. Auditing everything is the default instinct and it's the reason clients run out of log capacity, because the volume tracks transaction count rather than data volume. Pick the tables and columns that a regulator, an auditor or a fraud investigation would actually ask about — money, status, ownership, consent, personal data — and leave the rest. The Common entities across Dynamics 365 apps shortcut on the Compliance page is a reasonable starting position for a Dynamics build and a bad one for a bespoke Dataverse app.

Configuration decisions

• Which tables and columns are in scope, decided against a written control requirement rather than "all of them".
• Retention period, and whether it's applied through the Compliance page so it also covers existing logs.
• Whether Log access (sign-in logging) and Read logs (retrieve and export logging into Purview) are on, and whether the licensing for the latter exists.
• Whether audit configuration is carried in a solution so it deploys consistently, rather than being set by hand per environment.
• Whether choice columns store the original label at the time of the change via StoreLabelNameforPicklistAudits, or show whatever the label says today.

Gotchas

• Audit records appear in Audit History and the Audit Summary view with a delay, because they're in log storage rather than the database. Users will report it as missing data.
• Turning auditing off for a column doesn't hide history retrospectively — but before-and-after values go to Purview as * from that point.
• Setting StoreLabelNameforPicklistAudits to true changes the Audit Summary view but leaves the model-driven app's Audit History showing the old behaviour. Two screens, two answers.
• The Record column filter in the Audit Summary view doesn't work and is being removed, and the Entity column's Equals filter returns nothing — use Contains.
• Deleting audit logs to reclaim capacity destroys the history for that period permanently. There's no partial recovery.
• Copy and restore exclude audit logs by default, so a refreshed sandbox has data with no history behind it.

Consultant notes

• Get the audit scope agreed in writing with whoever owns the compliance requirement, and attach the log capacity forecast to it. That document ends the "why is our storage full" conversation before it starts.
• Users need View Audit History for a record's history and View Audit Summary for the environment-wide view. These are separate privileges and neither is in the standard roles by default — check them during security design.
• Delete Audit Record Change History is the privilege that lets someone erase a record's audit trail for a DSR. Treat it as a high-privilege right and give it to almost nobody.
• If the client wants real audit reporting, plan for Synapse Link and Power BI from the outset. The in-product views are for investigations, not analysis.

---

Worth revisiting if audit retention becomes available on CMK environments, or if the Audit Summary view finally gets an export.