Dataverse auditing step by step: track who changed an account phone number

A phone number changes on an account and somebody asks who edited it. The current record shows the latest value, but that does not explain the change. This tutorial configures Dataverse auditing and proves the result with two controlled saves, so you can check the user, time and before-and-after values.

Before you start

Use a sandbox with Dataverse and an existing model-driven app that includes Account. You need System Administrator, System Customizer or equivalent configuration permissions. The person inspecting history needs the View Audit History privilege, plus appropriate access to the account. Confirm available log capacity with your administrator.

We will use an account called Audit Training Account and the standard Main Phone column, logical name telephone1. Use only synthetic information. A training value such as TEST-A makes the change easy to recognise without exposing a real person's details.

Bijay Kumar's SPGuides walkthrough highlights a frequent misunderstanding: Dataverse row history comes from auditing, while restoring a canvas app version is a separate feature. Here, the acceptance test is to find one specific field change after enabling the required settings.

How to implement it

1. Enable the environment. Open the Power Platform admin centre, select Manage, Environments and your sandbox. Open Settings, then Audit and logs, then Audit settings. Turn on Start Auditing and save. If your interface exposes this through Global Audit Settings, open that link, enable Start Auditing and confirm. Select a retention period approved for your test environment.
2. Enable the table. At make.powerapps.com, select the same environment. Open your unmanaged solution and add the existing Account table if needed. Open the table properties, expand Advanced options and select Audit changes to its data. Save. Work inside the solution so the table configuration remains reviewable.
3. Enable the column. Open Account, then Columns, and locate Main Phone using logical name telephone1. Open Advanced options, confirm Enable auditing is selected and save. Publish the table customisations. An enabled column alone is insufficient: the environment and table must also be enabled.
4. Save the first value. Open your model-driven app and create Audit Training Account. Set Main Phone to TEST-A and save. Note the environment, record and signed-in user so you can distinguish this test from other activity.
5. Make a measurable change. Change Main Phone from TEST-A to TEST-B and save again. Change only that field for this test. Saving the same value does not demonstrate an audited update. The two distinct saves give you an unambiguous expected old and new value.
6. Inspect the history. On the account form, select Related, then Audit History. Use Filter on to select Main Phone. Find the update and inspect its details for TEST-A, TEST-B, the acting user and time. Logs can appear after a delay; refresh before concluding the setup failed.

The navigation follows Microsoft's auditing administration guide. Labels can vary by interface version. If your app omits Related or Audit History, ask its maker to expose the relevant navigation rather than assuming there is no underlying log.

Check the configuration independently

Developers can verify metadata through the documented auditing properties. With an authenticated Dataverse Web API client, send this read-only request to your organisation:

GET /api/data/v9.2/EntityDefinitions(LogicalName='account')?$select=LogicalName,IsAuditEnabled
Accept: application/json
OData-Version: 4.0
OData-MaxVersion: 4.0
If-None-Match: null

Check that IsAuditEnabled.Value is true. This verifies the table setting only; it does not prove the environment or telephone1 is enabled, or that the viewer has permission. Keep credentials in the authenticated client rather than pasting tokens into shared notes.

Troubleshoot against the expected result

• No changes appear: confirm the same environment is selected in both portals, inspect all three audit settings and publish the customisations.
• Other fields appear but Main Phone does not: verify telephone1 and repeat a genuine value change after configuration. Enabling auditing does not reconstruct older changes.
• An administrator sees history but a colleague cannot: review the colleague's record access and View Audit History privilege. Avoid granting broad administrator access merely to solve a viewing problem.
• The user is an application identity: investigate the integration or automation that performed the write. Do not assume every update originated from a person editing the form.

Keep the scope and retention deliberate

Microsoft's developer overview distinguishes organisation, table and column auditing controls. Treat this exercise as configuration for one business question. Broadly enabling every column can produce history that is expensive and difficult to review.

Audit data consumes log capacity. Agree retention, access and deletion ownership before production rollout. If you disable a temporary test setting, document the resulting coverage gap. Deleting logs removes evidence; restoring the phone value does not erase its recorded changes.

Mauro's insight

I would ask the support person to demonstrate the history using their normal account before calling this complete. The useful outcome is an authorised colleague explaining a real change, not an administrator showing that three switches are enabled.

Record the expected and observed values, the user and the time for your test. Repeat with another business-critical column when the first example works. Audit history helps investigate changes; it does not provide automatic rollback or replace a recovery plan.