NXTGN Capacity Control Sign up

The Dataverse audit log: growth, retention period and safe reduction

By Tobias LehmeierPublished Facts as of:

The Dataverse audit log, which the admin center calls “Auditing”, shows who changed what and when. It takes up log capacity, and log storage can borrow only from unused database capacity. From 9 November 2026, Microsoft restricts tenants over their entitlement in stages (deadlines and checklist). This article explains why the log grows, what role the retention period plays and how to reduce the log without losing evidence.

What log storage contains

Microsoft counts three things toward log capacity: the audit table AuditBase, the plug-in trace logs in PlugInTraceLogBase and elastic tables. A daily Dataverse job removes plug-in trace logs after 24 hours; what can grow for years is mainly the audit log and elastic tables. Even so, if the plug-in trace log setting is “All” in production, new entries are created all the time; Microsoft recommends “Off” there.

Why the audit log grows

  1. Every value change in an audited column creates an entry. Dataverse logs the creation, update and deletion of records, sharing, N:N associations and changes to security roles. An update creates an entry only if the value actually changes.
  2. Many tables at once. The option “Common entities across Dynamics 365 apps” (Power Platform admin center › Security › Compliance › Auditing) turns on auditing for 40 standard tables, including Account, Contact, Lead, Opportunity, Quote, Order, Invoice and Case.
  3. Integrations and automation. Interfaces, flows and plug-ins that set fields regularly create an entry with every value change, with no person involved, for example a nightly sync that transfers status or date fields from an ERP system.
  4. Access logging. If “Log access” is turned on, Dataverse logs user sign-ins. The useraccessauditinginterval column sets the interval; the default is 4 hours.
  5. No retention limit. If retention is set to “Forever”, Dataverse deletes no entries. The log then grows with every month of operation.

How to measure

  • Total volume: Power Platform admin center › Licensing › Dataverse › Environment › Consumption per table, storage type Log. The audit log appears there as one table: AuditBase.
  • Share per table: The Web API action GetAuditStorageDetails returns the audit size per table; Microsoft describes the call in the article “Recover database space by deleting audit logs”. The calculation runs asynchronously: if at first only a status comes back, call the action again later.
  • Rough conversion: In our development environment, one audit entry took up about 1,400 bytes of log capacity (measured on a table with 12,230 entries). 1 GB therefore corresponds to roughly 700,000 entries. Your figure depends on how many columns are logged per change.

The retention period: auditretentionperiodv2

How long Dataverse keeps audit entries is set in the auditretentionperiodv2 column of the organization table, in days. The value -1 means “forever”; any other value is the period in days.

  • Read it: GET organization URL/api/data/v9.2/organizations?$select=auditretentionperiodv2
  • Set it: Power Platform admin center › Manage › Environments › environment › Settings › Audit and logs › Audit settings › “Retain these logs for”. Alternatively: Security › Compliance › “Auditing” tile.

Three things to know about the retention period:

  1. Each entry gets the retention period that applies at the moment it is created. A change in the environment settings affects only new entries. Microsoft’s example: if the period is extended from 30 to 90 days, Dataverse still deletes the older entries after 30 days.
  2. Through Security › Compliance, you can also apply the period to existing entries. A shorter period then applies to the existing history as well.
  3. Microsoft’s documentation is inconsistent about the default. The administrator page says “Forever”, the developer page says 30 days. Read the value of your environment instead of assuming it.

The risk of a retention period that is too short

A short retention period reliably lowers log storage and continuously deletes history in the process. Dataverse removes every entry as soon as it is older than the period, without asking and without a recycle bin. Microsoft states that deleted audit logs are not recoverable.

After that, there is no evidence of who changed a price, an address or a security role, or who deleted a record. Internal audit, external auditors or customers ask such questions years later, too.

That is why you should set the period together with internal audit and data protection. The yardstick is the longest period over which you must be able to prove changes, not the storage available. If you archive, you need a second rule: the period in Dataverse must be longer than the interval until the export. Otherwise entries disappear before they reach the archive.

Archiving instead of deleting

In its storage management guidance, Microsoft recommends keeping audit logs in your own storage (“Audit logs: Retain it in your own storage”). These are the options:

Options for keeping audit logs
OptionWhat it doesLimits
Dataverse long-term retentionkeeps inactive business data read-only in Dataversedoes not take audit tables
Azure Synapse Link for Dataversereplicates the audit table to your Azure storageonly with the Delta Lake profile, which new customers can no longer use from 15 October 2026 (existing customers until December 2027); audit tables with more than 100 million entries are not synchronized; requires a Synapse workspace and a Spark pool; deletes nothing in Dataverse
Your own scripts using the Web API or SDKexport to your own specifications; Microsoft points to this option because the admin center offers no exportcompleteness, safe deletion and readability are up to you
NXTGN Capacity Controlexports every completed month per table to your Azure Blob Storage, verifies every audit ID in the archive and removes entries only after that, following your rulearchive currently only in Azure Blob Storage

With NXTGN Capacity Control, archived entries remain readable in the app and in the record’s history, even after the contract ends. In our test environment, 1 GB of audit data took up about 0.17 GB in the archive.

Safe reduction in five steps

  1. Measure. Log consumption in the admin center, the share per table through GetAuditStorageDetails, plus the retention period that is set.
  2. Check the inflow. Turn off auditing where nobody needs evidence, for example for technical columns that an interface rewrites constantly (Power Apps › Tables › table › Columns › column › Advanced options › “Enable auditing”). Agree on access logging with data protection and the works council.
  3. Set the retention period. Together with internal audit and data protection. If you archive: longer than the interval until the export.
  4. Archive, verify, then delete. Export older months and check that they are complete. Only then delete in Dataverse, for example in the admin center under Manage › Environments › environment › Auditing › “Delete audit logs”. Note: “By table” deletes all entries of the selected tables, “All logs up to and including the selected date” deletes the entries of all tables up to that day. Microsoft gives a guideline of about 100 million deleted entries per day; the capacity report shows the effect after up to 72 hours.
  5. Repeat every month. Each month, another month of entries is added. A fixed schedule keeps the log small. NXTGN Capacity Control does this work following your rule.

Sources