Auditing a Customer Service deployment

What it does

Dataverse auditing records who changed what and when, and surfaces it as audit history on the record. On a service desk it's what answers "who reassigned this case", "who changed the SLA", and the compliance question about access to customer data.

Key facts

Auditing has three switches and all three must be on for a column to be audited: environment level, table level, and column level. Any one of them off means no data.
Environment level lives in the Power Platform admin center under Security > Compliance > Auditing: Start Auditing, Log access (sign-ins), and Read logs (sends read events to Microsoft Purview).
Table level is the "Audit changes to its data" checkbox in the table's advanced options. Column level is "Enable auditing" on the column.
There's a quick-enable option, Common entities across Dynamics 365 apps, that switches on around forty standard tables including Account, Contact and the usual suspects.
Retention defaults to Forever. A custom retention policy accepts up to 24,855 days.
Changing the retention period only stamps records created afterwards. Existing audit rows keep the retention they were written with.
Audit data consumes log storage capacity, which is billed and reported separately from database capacity.
Individual attribute values are capped at about 5 KB in the audit record, so long text changes are truncated.
Deleting audit logs is asynchronous and slow: roughly 4 million rows an hour, about 100 million a day. Bulk deletion in the environment's data management area is where you do it, by table, by access log, or up to a chosen date.
Audited operations include create, update and delete, sharing privilege changes, N:N associate and disassociate, security role changes, and deletion of audit logs themselves.
Not audited: table and column definition changes, authentication events, and retrieves unless Read logs is on.
Separate privileges control the experience: View Audit History, View Audit Summary, and Delete Audit Record Change History. Turning auditing on or off needs System Administrator or System Customizer.
Twenty-six non-customisable tables cannot be audited at all, ActivityPointer and Annotation among them.

When to use / skip

Turn it on. Every regulated client needs it, and every unregulated client eventually asks a question that only audit history can answer. The judgment call isn't whether, it's how much.

Where to be disciplined: don't enable auditing on every column of every table because the checkbox is there. Audit the columns that carry consequence — case owner, status, resolution, priority, entitlement, SLA fields, customer, and any column your client's regulator names. Auditing free-text description fields on a high-volume case table generates enormous log volume for material nobody ever reads.

Read logs is a different decision again. It answers "who looked at this customer's data", which is a genuine requirement in financial services and health, and an expensive luxury everywhere else.

Configuration decisions

Which tables and which columns are audited, agreed with whoever owns the client's compliance position rather than assumed.
Whether Log access is on, which is usually cheap and usually worth it.
Whether Read logs is on, which is neither.
The retention period: Forever, or a defined number of days that matches the client's records policy. Set it before you accumulate data, because it only applies going forward.
Who holds View Audit History and View Audit Summary — supervisors, or only a compliance role.
Whether auditing configuration travels in a solution or is applied per environment by runbook, and whether non-production environments audit at all.

Gotchas

The three-level switch is the classic trap. Table auditing looks enabled, the environment switch was never turned on, and there's no history for the period nobody checked.
Retention changes are not retrospective. A client who runs Forever for two years and then sets 90 days still has two years of rows and a bill to match.
Audit log storage is a separate capacity line. It's a common source of an unexpected overage invoice on a busy service desk.
Deleting audit data to recover capacity takes days at realistic volumes. It is not an emergency remedy.
The 5 KB attribute cap means audit history on long text is incomplete, which undermines it as evidence for exactly the fields people assume it covers.
Annotation can't be audited, so "who changed the note on this case" has no answer through this mechanism.
Auditing configuration is metadata and moves in solutions, which means a careless import can switch auditing off on tables in production.

Consultant notes

Agree the audited column list in a workshop and keep the signed-off version. When someone asks two years later why a field wasn't audited, that document is the whole answer.
Set the retention policy on day one. It's the single decision that costs money if you leave it.
Show the client where audit history appears on the case form, and who can see it. Supervisors usually assume they can and often can't.
Check log storage consumption at the end of the first month post go-live and extrapolate. Better to trim the column list early than to delete rows later.
Push back on "audit everything". It's not a security posture, it's a capacity problem with a compliance justification attached.

Worth another look if log storage consumption jumps, or if the client's regulator changes its retention expectations.