Last updated: November 13, 2026
By ZapAI Team
Dataverse auditing records who created, changed, shared or deleted records in a Dynamics 365 or model-driven Power Apps environment, and it’s the first thing an auditor asks about in any Microsoft Dataverse system. It isn’t one switch. It’s three levels of settings, a separate Purview feed for reads and exports, a retention clock, and a storage bill. This guide covers all four, plus long term data retention and bulk delete.
Turn on Dataverse auditing at three levels, environment, table and column, to log who changed what and when. Add Read logs to send record views and exports to Microsoft Purview. Then set a retention period, because audit logs consume Dataverse log capacity.
Here’s the problem we keep running into. Somebody asks a simple question, like who opened a patient record or who exported the pipeline to Excel, and the admin discovers that the setting that would have answered it was never on. Auditing can’t go back in time. Whatever wasn’t captured is gone.
So we start with the questions, map each one to the setting that answers it, then cover retention, capacity, export and deletion. Product facts were checked against Microsoft Learn in November 2026. One more thing. This is not legal advice.
What Is Dataverse Auditing?
It’s the built-in change log for Dataverse tables. Once it’s on for an environment, a table and its columns, Dataverse writes an audit record for each create, update, delete, share, association and security role change, with old and new values for audited columns.
Microsoft’s Manage Dataverse auditing guide lists what’s covered. Creates, updates and deletes. Sharing changes. Record associations. Security role changes. Even audit log deletions. Updates only log when a value actually changes.
What it doesn’t cover matters just as much. Auditing skips table and column definition changes, authentication, and every read or export. Those need activity logging in Microsoft Purview. Different feature. Different license questions. Different retention clock.
Audit records live in the Audit table and count against Dataverse log capacity, alongside plug-in trace logs and elastic tables, which is also why they can reach a record’s Audit History tab after a short delay. Large text gets trimmed. An audited email description stops at about 5,000 characters.
Which Audit Setting Answers Which Question?
Each audit question maps to one setting and one place to look. Change history lives in Dataverse. Reads, exports and admin actions live in Purview. Get the mapping wrong and you’ll have plenty of logs. Still no answer.
| Question | Setting that answers it | Where you look | Whose storage and retention |
|---|---|---|---|
| Who changed this field, and what was the old value? | Table auditing plus column auditing | Audit History tab on the record | Dataverse log capacity and retention setting |
| Who deleted this record? | Table auditing | Audit Summary view | Dataverse log capacity |
| Who gave this user a new security role? | Environment auditing, which captures security role changes | Audit Summary view | Dataverse log capacity |
| Who signed in, and when? | Log access, recorded every 4 hours per user by default | Audit Summary view | Dataverse log capacity |
| Who opened this record? | Read logs plus the table’s Single record auditing setting, production only | Microsoft Purview audit search | Purview, 180 days unless licensed and extended |
| Who exported this view to Excel? | Read logs, production only | Microsoft Purview audit search | Purview retention policies |
| Who changed environment settings or data policies? | Power Platform admin activity logging, on by default | Microsoft Purview audit search | Purview retention policies |
Two rows deserve a warning. “Who opened this record” needs Read logs, the table’s Single record auditing setting and a production environment, all at once. And the Excel row has a gap, because Microsoft’s Dataverse activity logging page says RetrieveMultiple and ExportToExcel events don’t reliably include record IDs, so you’ll know someone exported a view but not always which rows.
Our rule of thumb, and it’s opinion. “Who changed” questions go to Dataverse auditing. “Who saw” and “who took” questions go to Purview.
How Do You Turn On Dataverse Auditing?
Start at the environment, then each table, then each column. You need System Administrator or System Customizer. Environment auditing alone doesn’t audit every table.
Environment level
In the Power Platform admin center, Security, then Compliance, then the Auditing tile offers Common entities across Dynamics 365 apps, which switches on auditing for about 40 standard tables like account, contact, opportunity, case, quote, role and user. The environment’s Audit settings page, under Settings and Audit and logs, holds three switches.
- Start Auditing turns change auditing on or off.
- Log access records sign-ins.
- Read logs sends reads to Purview. It only appears when your Microsoft Office licensing meets Microsoft’s minimum.
Table and column level
Table and column flags live in Power Apps. Tick Audit changes to its data in the table’s Advanced options, then Enable auditing on each column. Publish. Microsoft recommends managing this through your normal ALM process.
Reads need two more table settings. With Read logs on, Microsoft says you also turn on Single record auditing, which logs a record when it’s opened, and Multiple record auditing, which logs every record shown on an opened page. Skip them and that table’s reads stay invisible.
Some tables can’t be audited at all. Microsoft lists 31, including Annotation (notes), Calendar, Workflow and WorkflowLog. Plan around that.
The Purview side
Purview needs its own setup. Turn on Enable SAS Logging in Purview under Privacy and Security for each production environment, and give reviewers the Audit Logs or View-Only Audit Logs role. Sandboxes send no user activity. Test there and you’ll see nothing.
How Long Are Dataverse Audit Logs Kept?
As long as your retention setting says, and the default depends on which Microsoft page you read. The admin guide lists Forever, with custom periods up to 24,855 days. Microsoft’s developer reference for auditing says AuditRetentionPeriodV2 defaults to 30 days and accepts up to 365,000. Check yours.
Retention is stamped on each log when it’s written. Change 30 days to 90 and old logs still expire at 30. Microsoft says the Security page auditing option can apply a new period to existing logs, while the Settings page can’t, and the ApplyRetentionToExistingLogs setting in the API is simply ignored if you try to update it. Use the Security page.
Expired logs get deleted continuously in the background, starting one second past the period. Customer Engagement on premises has no retention setting.
Which period should you pick? Our view is that Forever is rarely right. It lets log capacity grow without limit. We’d rather see a fixed Dataverse period that covers day-to-day investigations, plus an export or a Purview policy for the long tail.
What Do Audit Logs Cost in Capacity, and How Do You Delete Them?
Audit logs fill Dataverse log capacity, and only expiry or deletion shrinks them. Deleted logs can’t be recovered. Export first.
Before deleting anything, find out where the bytes are. Microsoft’s GetAuditStorageDetails action returns audit storage by table. In our projects the culprit is usually a high-volume table that an integration updates all day long, not the tables your auditors and managers actually open and review every week.
| Deletion option | What it removes | Typical use |
|---|---|---|
| By table | Audit logs for the tables you pick | Clearing a noisy integration table |
| Access logs, by people and systems | All sign-in logs for every user and system | Trimming access history you no longer need |
| All logs up to and including a date | Everything on or before that date | Applying a retention rule by hand |
| Delete Change History on one record | Every audit log for that record | A customer’s request to delete their data |
| BulkDelete API against the audit table | Audit rows matching a query, such as action 64 for web access | Targeted or recurring cleanup |
Deletion runs as a background job at roughly 100 million records a day, per Microsoft, and you track it under Bulk deletion in the environment’s data management settings. Single-record deletion needs the Delete Audit Record Change History privilege. Developers can’t delete Audit rows directly.
Now the trade-off. Every deleted log is evidence you no longer have, every kept log is capacity you pay for, and when a tenant goes over its entitlement Microsoft first blocks environment create, copy and restore operations, which tends to surface at the worst possible moment. So keep what answers a real question. Export what you must retain. Delete the rest on a schedule.
Where Does Microsoft Purview Fit?
Purview holds the activity side, meaning reads, exports, report views and admin actions. Not field history. Microsoft says column before and after values for creates, updates and deletes aren’t sent to Purview, so a Purview-only plan can show that a record changed but not what it said before the change.
That gap matters for the layered approach in Microsoft’s own training module, which pairs short Dataverse retention with multi-year Purview retention. Fine for “who touched what.” Useless for “what was the old value” once Dataverse logs expire.
Retention in Purview has its own rules, set out in Microsoft’s audit log retention policies page. Audit Standard keeps records 180 days. Keeping them up to a year requires the user who performed the activity to hold Office 365 E5, Microsoft 365 E5, Microsoft Purview Suite or the E5 eDiscovery and Audit add-on, and the 3, 5, 7 and 10 year options also need the 10-Year Audit Log Retention add-on.
Here’s the catch. The one-year default policy covers only Entra, Exchange, OneDrive and SharePoint records, even for E5 users. Power Platform activity stays at 180 days until you create a custom policy for those record types. Build one early.
Admin activity works differently. Microsoft’s Power Platform admin activity page says that collection is on by default for every tenant and can’t be turned off. It covers environment lifecycle events, property changes, data policy edits, lockbox requests and billing policies.
Agents are a newer wrinkle. A September 2025 Microsoft Power Platform blog said Dataverse audit trails now separate AI agent changes from human ones, with a filter for agent type in the new Audit Summary view of the Environment Settings app. We haven’t found that on Learn. Test it first.
For Purview in the analytics world, see our Microsoft Fabric governance guide. Copilot and agent monitoring sits in our AI governance framework.
How Do You Keep Audit Data Longer Without Paying for Log Capacity?
Export it. Today Microsoft supports Audit table export only through Azure Synapse Link profiles that write Delta Lake, an option closed to new customers on October 15, 2026. Link to Fabric doesn’t sync the Audit table yet. Microsoft says it will soon.
The details sit on Microsoft’s audit data with Azure Synapse Link page, updated October 9, 2026. Eligibility is checked per Dataverse organization ID, so a brand-new environment can’t use it even when a sibling environment can, and existing Delta Lake customers must move to CSV output or Link to Fabric by December 2027. Audit tables above 100 million records aren’t supported. The Spark pool bills per job.
Everyone else falls back to code. The Web API and SDK retrieve audit history with RetrieveRecordChangeHistory and related messages, since Microsoft’s auditing guide says exporting audit logs from the admin experience isn’t currently supported and points developers to those APIs instead. The September 2025 blog described export from the new Audit Summary view, though. Sources disagree. Check yours.
For Purview activity data, the Office 365 Management Activity API is the long-term route into a SIEM. Our Dataverse Link to Fabric comparison covers routing for business tables.
What Is Dataverse Long Term Data Retention?
It’s a Dataverse feature that moves inactive rows into a read-only long term store inside Dataverse, using retention policies you define per table. Retained rows can’t come back. It requires a Managed Environment, and it doesn’t support the Audit table.
Microsoft’s long term data retention overview says policies created in an unmanaged environment stay disabled, Dynamics 365 customers included, and Managed Environments bring licensing with them, because every user running an app there needs a premium Power Apps, Power Automate or qualifying Dynamics 365 license. Unlicensed users get blocked from opening apps starting February 2027, per the Managed Environments licensing page. Our Power Platform governance guide covers that call.
How it behaves
- Standard non-system tables and custom tables qualify, with attachments and images. Audit and elastic tables don’t.
- A policy on a parent table pulls in its child tables.
- Delete cascades and delete plug-ins run during a policy run. Test them.
- Runs consume API requests and take 72 to 96 hours, sometimes up to two weeks.
- One policy executes at a time. Running policies can’t be stopped.
- Retained data is readable through Advanced Find, Power Automate or the OData API. Slowly.
- Customer-managed key environments, GCC, GCC High and DoD aren’t supported.
Capacity savings are real but partial. Microsoft says retained data uses on average 50% less database capacity thanks to compression. File attachments see none. The long term retention FAQ adds that retained data can’t move into your own data lake, though Fabric can read it for Power BI.
When Should You Use Bulk Delete Instead?
Use bulk delete when data has no remaining business, legal, audit or recovery value. Use long term retention when you must keep it but don’t need it daily. Microsoft’s own Dataverse governance page draws that exact line.
Bulk deletion jobs come from the Bulk Deletion Wizard in the environment’s data management settings, run once or on a recurring schedule, email you when they finish, and log failures on a Run details tab, as Microsoft’s bulk delete guide explains.
Three settings change how forgiving it is.
- Keep deleted Dataverse records holds deleted rows for 1 to 90 days for restore. They still count toward storage, per Microsoft’s restore deleted records page.
- Permanent deletion, a wizard checkbox, skips that safety net. Faster. Irreversible.
- Bulk delete jobs can travel inside your ALM packages, and Microsoft warns that imported jobs run immediately on import.
That last point bites. Picture a hypothetical. A sandbox job built to delete test cases older than 30 days ships to production in the next release. It runs the moment the import finishes. Read every Data Life Cycle Config item before a release moves.
What Should a Dataverse Retention Schedule Look Like?
One row per data type, with a keep period, a mechanism and an owner. Below is a ZapAI starting point for SMB and mid-market Dynamics 365 teams, not a legal standard. Confirm every period with counsel and, where they apply, regulators.
| Data type | Where it lives | ZapAI starting point | Mechanism | Confirm with |
|---|---|---|---|---|
| Leads and closed opportunities | Lead, opportunity and child tables | Live 3 years after close, then long term retention | Retention policy on the parent table | Sales ops, counsel |
| Sales activities | Phone call, task, appointment tables | Live 2 years after completion, then retain or delete | Retention policy or recurring bulk delete | Sales ops |
| Cases and case notes | Case and child tables | Live 2 years after the case closes, then long term retention | Retention policy on case | Service lead, counsel |
| Emails and attachments | Email and attachment tables | Live 1 to 2 years, then retain or delete by mailbox purpose | Retention policy or bulk delete | Records manager |
| Dataverse change audit | Audit table | 1 to 2 years in Dataverse, exported first if you need longer | Audit retention setting plus export | Compliance |
| User access logs | Audit table | 90 days to 1 year | Delete access logs | Security |
| Purview activity logs | Microsoft Purview | 180 days by default, longer only by policy and license | Purview audit retention policy | Compliance |
| Plug-in trace logs | Plug-in trace log table | 30 days or less outside active debugging | Recurring bulk delete | Developers |
Two notes. Start retention from an event like close date, not creation. And a legal hold beats any row in this table, so build a simple way to pause deletion for a named account, contact or case before you schedule a single job.
Cases deserve their own look, since service teams tend to keep everything forever. Our Dynamics 365 Customer Service guide covers the case model.
What Do HIPAA and Financial Services Rules Change?
They add obligations that don’t all point the same way. Some push you to log and keep. Others push you to dispose. Counsel decides how they apply.
Healthcare
The HIPAA Security Rule’s audit controls standard, 45 CFR 164.312(b), asks for mechanisms that record and examine activity in systems containing electronic protected health information, but it doesn’t name a log retention period. The six-year figure people quote comes from 45 CFR 164.316(b)(2)(i), which covers required documentation like policies and records of required actions and assessments. Whether audit logs fall under it is a question for counsel.
In Dataverse terms, our checklist for PHI environments includes Read logs in production, column auditing on PHI fields, and one written retention plan covering Dataverse and Purview. Our Dynamics 365 HIPAA guide covers the BAA side, and our healthcare team works on these builds.
Financial services
Non-bank financial institutions under the FTC Safeguards Rule face both pressures at once, since section 314.4(c)(8) asks them to monitor and log authorized users’ activity while 314.4(c)(6)(i) asks them to dispose of customer information within two years of last use, with exceptions, per the Safeguards Rule text. Broker-dealers face SEC Rule 17a-4, with three-year and six-year preservation periods and conditions for electronic records. We haven’t seen Microsoft claim that Dataverse long term retention meets them. Don’t assume it.
Banks and credit unions answer to their own examiners. Our banking practice starts from the compliance team’s existing records schedule, not from Dataverse.
What Mistakes Do We See Most With Dataverse Auditing?
Mostly gaps between what people think is on and what is.
- Turning on environment auditing and assuming tables follow. They don’t.
- Auditing every column on a table an integration updates hourly
- Leaving retention at Forever because nobody chose a number
- Testing Read logs in a sandbox. Purview only gets production activity.
- Counting on Purview for previous field values it never receives
- Assuming E5 keeps Dataverse activity for a year. Not without a custom policy.
- Deleting audit logs to clear a capacity alert before exporting
- Shipping a bulk delete job inside a release unread
Dataverse Auditing and Retention Checklist
Work through it in order. It’s our practice, not a Microsoft rule.
Decide
- List the questions auditors actually ask.
- Map each to Dataverse auditing, Read logs or Purview admin logs.
- Draft the retention schedule. Get counsel’s sign-off.
Configure
- Environment auditing on, with a deliberate retention period
- Table and column auditing set through ALM
- Read logs, SAS logging and table read settings on in production
- Purview roles assigned. Custom retention policy for Power Platform records.
Retain and delete
- Check audit storage by table quarterly.
- Export what you must keep beyond the Dataverse period.
- Test retention policies in a sandbox.
- Legal hold process ready.
Prove
- Run a mock audit. Ask who changed a field, who opened a record, who exported a view.
- Time each answer.
- Write down its source.
Settle this before go-live, alongside the security and compliance step in our Dynamics 365 CRM implementation checklist.
What Could Change After Ignite 2026?
Possibly a few things. Ignite runs November 17 to 20, 2026, in San Francisco, and we’ll refresh this post afterward.
Our watch list. Audit table support in Link to Fabric. The license gate on Read logs. Agent audit events on Learn. Dataverse storage advisor, now a preview, reaching general availability.
Wrapping Up
Dataverse auditing answers “who changed what.” Purview answers “who saw or took what.” Retention settings decide how long each answer survives, log capacity decides what it costs, and long term retention and bulk delete handle the business data itself, so set all four on purpose and then test them with a real question before an auditor does.
ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Dataverse consultants configure auditing, Purview logging, retention policies and exports, and our Dynamics 365 team handles the apps on top. Want a second look first? Ask us for a Dataverse audit and retention review, and we’ll map your questions to settings before anything gets deleted.
Questions Admins Ask About Dataverse Auditing
Is Dataverse auditing turned on by default?
Don’t assume it. Check Audit settings in the Power Platform admin center, then each table and column, because environment auditing alone doesn’t audit every table. Read logs and Log access are separate switches.
Can Dataverse auditing show who viewed a record?
Only through Microsoft Purview. Turn on Read logs, the table’s Single record and Multiple record auditing settings, and SAS logging. Purview captures this activity for production environments only.
How long does Dataverse keep audit logs?
As long as the retention setting says. Microsoft’s admin guide lists Forever as the default with custom periods up to 24,855 days, while the developer reference lists 30 days. Check your environment.
Do audit logs count against Dataverse storage?
Yes, against log capacity. Delete logs by table, by access logs or by date to reclaim space. Deleted logs can’t be recovered.
Can long term data retention keep audit logs?
No. Microsoft’s FAQ says the Audit table isn’t currently supported. Use the Dataverse retention setting, Purview policies or an export instead.
Do I need Managed Environments for long term data retention?
Yes. Retention policies in an unmanaged environment stay disabled, Dynamics 365 customers included. Managed Environments also require premium or qualifying Dynamics 365 licenses for active users.
Can I send Dataverse audit logs to Microsoft Fabric?
Not directly yet. Link to Fabric doesn’t sync the Audit table today, though Microsoft says support is coming. Eligible existing organizations can export it through Azure Synapse Link Delta Lake profiles until December 2027.