Auditing
Auditing can be enabled on Microsoft Dataverse data to track changes. Auditing can be used to satisfy compliance requirements, or simply to allow users to see what data has been changed on a row. Data change auditing, is configured at the Dataverse environment, table, and column level. Enabling and disabling of auditing can only be done by someone in the System Administrator or System Customizer role.
In addition to auditing when data changes, Dataverse also supports user access auditing to capture sign-in and read auditing, allowing monitoring of data usage by a user. Log viewing for data changes is done from the Power Platform admin center or from a model-driven app. Log viewing for read and other activity auditing data is done from the Microsoft Purview compliance portal.
Most of the time, an administrator will configure auditing at the environment level, such as enable or disabling auditing, or specifying what to audit. This will be done in each environment used. For example, you would individually turn on auditing in your development, test, and production environments. A maker building apps and managing Dataverse table and column definitions will configure auditing for the relevant tables and columns. Any audit settings that you configure for tables and columns can be transported across environments using solutions. The solution being imported into test and production ensures consistent auditing settings and avoids manual configuration in each environment.
Note
Auditing settings for tables and columns are solution aware and will be transported with the schema as the solution is installed in another environment. However, each environment must have auditing enabled at the environment level for these settings to perform as expected.
Environment settings
Auditing is disabled by default in each Dataverse environment and must be manually enabled using the Power Platform Admin Center. If disabled at the environment level, no auditing data is captured, even if auditing is configured for tables and columns in the environment.
Enabling and disabling auditing for an environment can be done from the Power Platform admin center by selecting an environment and choosing the Settings button at the top. The Audit and Logs section provides access to the different auditing features.
Audit settings
The audit settings area provides the ability to configure basic auditing settings in the environment. You can perform the following:
Start auditing: Enables data change auditing and uses Dataverse log capacity.
Log access: Logs whenever the system is accessed. This is done when someone logs into the application.
Read logs: Sends logs so they can be viewed in the Microsoft Purview compliance portal.
Audit summary
The audit summary view lets administrators view auditing data collected across all Dataverse tables in one place. For data changed events like an update, you can drill down and see which column values were included in the update action.
You can also access the entity and field audit settings here to view and configure auditing at the table and column level. This is best used for viewing, and if you need to configure, you should follow the steps later in this unit and do the change from the maker portal.
An important take away from an admin perspective is that you might have access to enable auditing in the development environment, but not in the other environments like test and production. For these, you must work with the environment administrator to get the setting enabled. It isn't uncommon for table and column auditing to be configured in development and not enabled in the other environments, causing lack of capture of audit data.
Enabling auditing on tables and columns
Auditing on tables and columns is configured on their definitions, either at creation or later by editing the settings. The state of auditing is tracked as part of the table and column metadata in solutions containing the table. When the solution is used to transport the definition from one environment to another such as from a development to testing environment, the audit settings are applied to the target environment. If you have the table in multiple solutions that are imported into the same target environment, the audit settings can be set by the most recent solution. When the solutions contain different configuration for the auditing settings one solution could turn them on and a newer solution could turn them off. Care should be taken to ensure all solutions containing the table are a consistent setting for the auditing configuration.
By default, new Dataverse tables that are created have auditing disabled. You can enable or disable auditing for tables using the classic solution explorer. When auditing is enabled for a table, auditing is enabled for all eligible columns of that table. When editing a column, you can find the auditing switch under the advanced options section on the column properties.
After changing any of the column audit configurations to enable or disable, you must publish changes for the table or publish all changes.
Configure multiple columns
If you're changing several columns, you might want to use the Edit Multiple Fields feature of the classic solution explorer. By selecting multiple columns in the list, you can enable or disable auditing everything selected.
Deciding when to enable or disable auditing
As part of creating each table, you should consider whether auditing would be valuable or not. Anytime you have compliance requirements around tracking who changed data and what the data changes are, auditing should be considered. Auditing can also be a good safety net to quickly restore data without having to go to a backup. For example, if a user accidentally changes a record or deletes it without auditing, your only option to recover the data is to restore a backup to find out what the values were. Using auditing, you could use the audit log data to know how to reconstruct the records prior to the change or the deletion.
Auditing of data changes consumes Dataverse log capacity. Audit data is retained based on a retention period configured for the environment. Retention isn't configured by table, so if you have a table with large or high-volume changes happening, you should carefully consider which columns require auditing. Audit logs can be deleted, except the current log.
Viewing audit data
In addition to administrators being able to see a summary view across all tables from the admin portal, Power Apps model-driven apps also provide a summary view related to each row that has auditing enabled. From the related tab in the row form view, you can navigate to an audit summary view for just that row.
From here, you can view a summary of the audit data for the current row. By selecting a row it can be exported, and by clicking on the event you can see a detailed view of what has changed as well as the full old and new values. Users with permission can delete the entire change history for the row.
Configuring security roles for auditing
Security roles offer multiple privileges related to auditing that can be granted to users as required. By default, System Customizer and System Administrator have some of these privileges enabled. These can be found in the miscellaneous section on the core records tab. When you grant users these privileges, keep in mind they apply to all tables, rows, and columns.
Some amount of auditing is useful in most solutions and should be part of the consideration anytime you add a new table or column to a Dataverse environment. Administrators should be consulted to ensure auditing is enabled and retention periods are configured to meet the business requirements.