Proving Who Changed What in Dynamics 365: Audit Trails That Survive a Regulator

Why do Dynamics 365 audit trails fail when a regulator asks for history?

Rarely because the platform cannot audit. The usual story is capacity. Audit records accumulate in log storage, someone sees the capacity report turning red, and auditing is switched off for noisy tables, scoped down to nothing useful, or old logs are deleted to free space. Nobody records the decision. Months later an auditor asks who changed a credit limit, a consent flag or a case outcome over the last two years, and the history is either missing or has a hole in the middle.

The fix is to separate two jobs that are usually treated as one. Operational auditing inside Dataverse answers day to day questions about recent changes. Evidential retention, the multi year record a regulator can rely on, belongs in storage designed for it. Once those are separate, you can keep auditing on without fighting over capacity. This page is technical guidance; what your regulator requires, and for how long, is for your compliance team and advisers to decide.

What does Dataverse auditing actually record?

Each audit record captures an operation on a row: which table and row, what kind of operation, who performed it (including when one user acted on behalf of another), when, and for updates the old and new values of each audited column that changed. Audit records cannot be edited through the application or the API, which is why they carry weight as evidence. They can, however, be deleted by anyone holding the relevant privilege, which matters later on this page.

How do you enable auditing and scope it to the columns that matter?

Auditing works at three levels, and all three must be on for a change to be recorded. The environment switch is in the Power Platform admin center under the environment's auditing settings, alongside the user access logging option. The table switch is the Audit changes to its data setting on each table in the maker portal. The column switch is the auditing option on each column, which is on by default for columns of an audited table.

That last default is where capacity goes. A table audited with every column on records every system or integration update to fields nobody will ever be asked about. Scope deliberately instead.

• Start from the evidence: list the questions an auditor or regulator could ask, such as who changed this limit, this status, this consent or this owner, and map each to a table and column.
• Turn on auditing for those tables, then turn column auditing off for technical, calculated or integration housekeeping columns that change constantly and carry no evidential value.
• Audit security: role assignments, team membership and business unit changes are evidence of who could do what, and are cheap to keep.
• Check integration users. An integration that rewrites every column on every sync creates an audit record per column change, so fix the integration to send only changed values rather than disabling the audit.
• Record the configuration: export the list of audited tables and columns with a date, and keep it with your compliance records. Solutions carry table and column audit settings, so review them in pull requests like any other change.

Does audit history count against Dataverse storage capacity?

Yes. Audit records are stored as log data and count against your log capacity, alongside plug-in trace logs. That is the pressure that causes most gaps: when the tenant goes over capacity, deleting audit logs looks like the quickest win. Our sibling guide on Dataverse storage capacity cleanup covers how to free capacity without touching evidence.

The environment also has an audit retention period setting in the admin center, which controls how long new audit records are kept before the platform removes them. The available periods and the defaults have changed over time, and changing the setting may only apply to records created afterwards, so check current Microsoft documentation before relying on it. Treat that setting as operational housekeeping. It should never be the only thing standing between you and a regulator's retention requirement.

How do you retrieve who changed a record through the Web API?

There are two routes. For one record's history with old and new values resolved per change, call the RetrieveRecordChangeHistory function with the record as the target. For a population, such as every change to a table in a period, query the audits entity set and filter on the audited record, the table and the date, then expand to details for the rows you need.

An illustrative pair of requests, shown as text rather than code to copy: GET [org]/api/data/v9.2/RetrieveRecordChangeHistory(Target=@t)?@t={'@odata.id':'contacts(<record id>)'} returns the change history of one contact. GET [org]/api/data/v9.2/audits?$filter=_objectid_value eq <record id> and createdon ge 2025-01-01T00:00:00Z&$orderby=createdon asc returns the audit rows for that record from a date. The caller needs the View Audit History privilege, and for bulk extraction you should page through results and run under a dedicated identity whose own access is logged.

Check parameter names and the shape of the returned audit detail against current Microsoft documentation for your API version. For an analyst who only needs to read one record's history on the form, our free Easy Audit PCF control turns the native audit grid into a sortable, filterable change history view with CSV export. It reads the audit data that exists; it does not retain anything beyond it, so it is a viewing tool, not a retention answer.

How do you export audit logs to long-term immutable storage?

Retention that survives a regulator lives outside the operational environment, in storage nobody can quietly edit or empty. The common patterns on the Microsoft stack are below. Each depends on current product capabilities and licensing, so validate the exact option against Microsoft documentation before designing around it.

Why is deleting audit logs to free capacity so dangerous?

Because it destroys the evidence and cannot be undone. The admin center lets an administrator delete audit logs to free capacity, for example by date or by table, and a single record's change history can also be deleted through the API. These are legitimate tools, used for personal data erasure among other things, but used casually they remove exactly the history an auditor will ask for.

Put three controls around them. Export first: no audit deletion runs until the export for that period is confirmed and reconciled. Restrict the privilege: few people, named in your access review. Record every deletion: date, scope, reason and approver, kept outside Dataverse. Deletion is also logged within auditing itself, but a log kept in the system being cleaned is not enough on its own. Where audit history holds personal data that must be erased, follow the process in our sibling guide on GDPR retention, erasure and DSARs in Dynamics 365 so erasure and evidence are handled deliberately rather than by a capacity cleanup.

What can you reconstruct for a period when auditing was off?

Some facts, never the full field-level history. Be honest about the difference before an auditor finds it. Useful sources, in rough order of reliability, are below.

How do you document an audit gap for an auditor?

Write a dated statement rather than hoping the question does not come up. Auditors can usually work with a known, explained, controlled gap; a hidden one found during fieldwork is far worse. Your compliance lead owns the statement, and the technical team supplies the facts.

• The period: the exact dates auditing was off or scoped down, for which tables and columns, evidenced from audit settings history, admin logs or change records.
• The cause: capacity pressure, a configuration error, a migration, stated plainly.
• What was reconstructed and from which sources, with the limits of each, and what cannot be reconstructed.
• Compensating evidence for the period, such as approvals held outside the system or source system logs.
• The controls since: auditing scope agreed and documented, scheduled export to immutable storage, restricted deletion privilege, and a periodic check that auditing is still on.
• The date the controls were verified as operating, and by whom by role.

How do you keep auditing from being switched off again?

Make the audit configuration a controlled setting rather than a toggle anyone with admin rights can change quietly. Keep audited tables and columns in solutions reviewed through your release process, check the environment and table settings on a schedule and alert when they differ from the documented baseline, and monitor the export job so a failed run is noticed within days. Where rules also need to be enforced at the point of data entry, such as mandatory reasons for a change, our sibling guide on closing a forms compliance gap in eight weeks covers that side, and building a CRM against a fixed audit date covers what an auditor usually samples.

If the underlying question is whether Dynamics 365 is the right place for a regulated record at all, answer it on requirements, not habit. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. A custom-built CRM on React, Node.js, PostgreSQL or .NET can use an append-only change log designed around your retention rules from day one, where that fits better.

How does Solzet help with Dynamics 365 audit trails?

We start by establishing the facts: what is audited today, what was audited in the period in question, where the gaps are and what the sources can reconstruct. Then we scope auditing to the evidence your compliance team needs, build and reconcile the export to immutable storage, put controls around audit deletion and capacity, and write up the gap so your compliance lead can present it. Where a wider review of security, configuration and ALM is warranted, that is our Dynamics 365 health check and technical audit.

Solzet delivers remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly or white-label for Microsoft partners.