Field Audit History — Inline Audit Trail for Dynamics 365

“Who changed this email address?” A sales rep asks me this on a support call. I walk them through it: open the record, click Related, click Audit History, scroll through a wall of every change on the entire record, click into an individual event, then mentally translate emailaddress1 to “Email.” Six steps. The rep says thanks and never checks audit history again.

Dataverse has one of the most powerful auditing engines in any CRM platform. It tracks every field change — who, when, old value, new value. Compliance teams love it. But the UI to access it? It’s like Microsoft built a vault and then hid the key behind five doors.

That’s why I built Field Audit History — a PCF control that puts audit data where users already are: right on the form, next to the field they’re looking at.

What It Does (Three Levels of Detail)

The control gives users three ways to access audit data, from fast to comprehensive:

1. Audit Icons on Field Labels

Small clock icons appear next to every field that has auditing enabled. Gray by default, blue on hover. Users can see at a glance which fields are being tracked — without clicking anything.

This alone changes the game. Instead of wondering “is this field even audited?” — you can see it instantly.

2. Quick Peek — One Click, Instant Answer

Click any clock icon and a compact popup appears anchored to that field. It shows the last 8 changes for that specific field: date, who changed it, old value → new value. No navigation, no panel loading, no context switching.

The popup includes a “Changed By” filter if multiple users made changes. Every entry has Copy and Restore buttons — copy a previous value to your clipboard, or restore it with one click. For that sales rep on my support call? This is all they’d ever need. One click, answer in two seconds.

Multiple people editing the same record? Use the “Changed By” dropdown right inside the popup to filter to a specific user’s changes.

3. Deep Dive — Full Sidecar Panel

Click the status bar (“Audit tracking · 4 fields”) or “View All” to open a wide panel covering 80% of the viewport. This is the power-user view:

• Visual timeline with color-coded operations — green for Created, blue for Updated, red for Deleted
• Human-readable field names — “Email” not emailaddress1, “Account Name” not name
• Four client-side filters — all instant, zero additional API calls

Opening the panel from a Quick Peek pre-filters to that specific field. Remove the filter to see everything. No re-querying — filtering happens client-side on already-loaded data.

Here’s the Field filter in action — select “Email” and the timeline instantly narrows to just that field’s changes:

Beyond Read-Only — Copy, Restore, Export

Audit history isn’t just for looking. Three action features turn it into a working tool:

Copy to Clipboard

Every audit entry has a Copy button. Click it to copy the old or new value — useful when a support rep needs to paste a previous email address into a ticket, or when you need the exact value from before a bulk update mangled your data.

Value Restore

See a wrong value? Click Restore on any audit entry to revert the field to its previous value. A confirmation dialog shows exactly what will change before anything happens.

This is the feature that gets the biggest reaction in demos. No more opening the record, finding the old value in audit history, manually typing it back, and saving. One click, confirm, done.

Export to CSV

Need audit data for a compliance report or external review? The Export CSV button in the Deep Dive panel downloads the entire loaded audit trail — filtered or unfiltered — as a CSV file. Dates, users, old values, new values, all in a spreadsheet-ready format.

The Native Audit UI vs. This Control

Let me be specific about what changes:

That last row is the one that matters. Dataverse audit data is genuinely useful — compliance, dispute resolution, troubleshooting. But if nobody can find it, it doesn’t exist. This control makes it visible.

How to Set It Up

No per-field setup. The control reads entity metadata on form load and auto-detects which fields have auditing enabled. If you enable auditing on a new field tomorrow, the icon appears automatically the next time someone opens the form.

Configuration: Make It Yours

The control ships with sensible defaults. But if you need control over which fields show icons, you can deploy a JSON web resource (vp365_AuditHistoryConfig) with per-table rules:

Example config for showing audit icons on specific fields only for the Contact table:

var config = {
    tables: {
        // Default: show on all audited fields
        "*": { mode: "audited", fields: [] },

        // Contacts: only these fields get icons
        "contact": {
            mode: "include",
            fields: ["emailaddress1", "telephone1", "jobtitle"]
        },

        // Accounts: audited fields minus system noise
        "account": {
            mode: "exclude",
            fields: ["modifiedon", "modifiedby"]
        }
    }
};

The wildcard "*" applies to any table without an explicit rule. You only need to configure the tables where you want something different from the default behavior.

The Gotchas Microsoft Doesn’t Highlight

I’ve deployed this in a production environment. Here’s what you need to know before you enable it:

Auditing must be enabled at three levels. Org-level (Settings > Auditing > Start Auditing), entity-level (table properties), and field-level (column properties). Miss any one of these and the field won’t show an icon. I’ve seen admins enable entity auditing and wonder why nothing appears — they forgot the field-level toggle.

Users need specific security privileges. Two privileges control audit data access:

If a user doesn’t have these, the control shows a clear error with the exact privilege names. The form keeps working — the control degrades gracefully, never crashes.

Lookups and option sets show display names, not GUIDs. This is actually a positive — the control uses OData annotation headers (Prefer: odata.include-annotations="*") to get formatted values. So you’ll see “John Smith” instead of a GUID and “Active” instead of 1. But this is worth knowing because if formatted values aren’t available for some reason, you’ll see the raw values as a fallback.

Client-side filtering means filters only work on loaded data. The Dataverse audit API doesn’t support server-side filtering by field name, user, or date. The control loads pages of audit entries (25 per page, up to 250 total by default) and filters in the browser. For 99% of use cases, this is plenty. If you have records with thousands of audit entries spanning years, you might need to increase audit.maxPages in the config.

Platform updates could break icon injection. The clock icons are injected by scanning the form DOM for field label elements using known Unified Interface patterns. If Microsoft changes their DOM structure, icons might stop appearing. But the form keeps working normally, and the Deep Dive panel (which doesn’t depend on DOM injection) still works from the status bar.

Performance

I was paranoid about form load time — nobody wants a PCF that makes their forms sluggish. Here’s what I measured:

The key architectural decision: audit data is only fetched on demand. The initial form load does two lightweight API calls in parallel — entity metadata and config. Actual audit records aren’t loaded until the user clicks an icon or opens the panel. So the 300ms overhead is for knowing which fields are audited. The heavy data only loads when someone actually wants to see it.

Who Should Use This

If you have Dataverse auditing enabled — and you should for any regulated or enterprise environment — this control makes that investment visible. The data is already being captured. This just puts it where people can see it.

Specific use cases I’ve seen work well:

• Compliance teams who need to verify field-level changes during audits without training users on the native audit sub-grid
• Sales managers tracking who changed deal amounts, stages, or close dates — the “someone moved my cheese” problem
• Support teams troubleshooting “this field used to have a different value” disputes
• Admins validating that automation (workflows, plugins, Power Automate) is writing the expected values

Get It

Field Audit History is published under the vp365 prefix and ships as a managed Dataverse solution. You can find the latest release on GitHub — download the ZIP, import it, and you’re live in under 10 minutes.

Solution name: vp365FieldAuditHistory Current version: 3.0.1 Publisher: vp365.ai React: 16.14.0 (platform-provided, virtual control) UI framework: Fluent UI v8

The control is read-only — it never writes to Dataverse. It reads entity metadata and audit history, nothing else. No external service calls, no telemetry, no data leaving your environment.

---

VP365.ai covers Power Platform and Dynamics 365 for practitioners who build and deliver — not just evaluate. More PCF controls and deep dives coming soon.