Operations
From the field archive · Learned in 2020
Storage Cleanup Before It Was a Crisis: Audit Logs, Plug-in Traces, System Jobs and Attachments
What I learned helping customers stay under their Dataverse capacity in 2020 and 2021, and how I'd handle the same four culprits with today's built-in settings.
In 2020 I spent a surprising number of weeks on one question from customers: "We're out of space again. What can we delete?" The capacity-based storage model was still new to most admins, and the answer was rarely the business data people were worried about. It was usually the housekeeping tables: audit logs, plug-in traces, system jobs and attachments.
Most of the cleanup that used to need a support request is now a setting in the Power Platform admin center. You can set an audit retention period and delete audit logs by table, by access logs, or by date. System jobs have a deletion service with retention you can adjust. Plug-in trace records are deleted automatically after 24 hours. Capacity reports break consumption down by table, and newer tools like the Dataverse storage advisor are still rolling out. What hasn't changed: nothing cleans up for you unless someone owns it.
This post is the archive version of a problem I now see from a different angle. My 2026 post on activity growth covers what happens once the obvious housekeeping is done and ActivityPointer becomes the story. This one covers the housekeeping itself.
01Why storage surprised people in 2020
When capacity moved to separate Database, File and Log meters, a lot of teams I worked with were still thinking in one number. They also didn't realize the entitlement is tenant-wide. A sandbox someone forgot about consumes the same pool as production.
That second point caused more friction than the first. In one large automaker, dozens of teams had their own environments, and the tenant went over capacity because of a few non-production instances. The first question in the room wasn't "what do we delete?" It was "who owns this environment?" That took longer to answer than the cleanup itself.
Storage is a shared budget. Before you clean anything, make sure every environment that consumes capacity has a named owner who can approve deletions.
02Audit logs
Audit logs are valuable. They answer who changed what and when. But in 2020 most environments I looked at had auditing turned on with no retention plan, and audit data grew quietly for years.
Back then, the self-service option in the app was limited. The legacy process lets you delete only the oldest audit log partition, one at a time. For environments with years of history, customers often asked for help to clear audit data in lower environments where they didn't need it. I handled several of those requests, and the reports in the admin center could take up to a day to reflect the change.
How I'd handle it today
- Set a retention period. Audit logs consume Log capacity, and the default retention is Forever. Pick a period that matches your compliance policy. Microsoft recommends setting it from the Security page, because that option can apply the policy to existing logs.
- Delete selectively. The newer delete process lets you delete by table, delete all access logs, or delete everything up to a date. It runs as a background system job you can monitor in the Bulk deletion view.
- Audit what matters. Auditing is configured at the environment, table and column levels. Turning on everything "just in case" is how Log capacity disappears.
- Treat deletion as permanent. Once audit logs are deleted, you can't view audit history for that period. Get compliance sign-off first.
In 2021 the same large automaker found several non-production field service environments carrying very large audit logs. They were the lowest-hanging fruit for getting back under capacity. Nobody needed years of audit history in a test environment. The cleanup was simple. Getting the right owners to agree took most of the time.
03Plug-in trace logs
Plug-in tracing helps developers debug custom code. The setting has three options: Off, Exceptions and All. All writes a trace record every time custom code completes, not just when it fails. In a busy development environment that adds up fast.
A genomics company I supported in 2020 started seeing "not enough space on the disk" errors from plug-ins and custom workflow steps in a development sandbox. They were close to their capacity limit, so the natural assumption was that they'd finally run out. The capacity report showed they were near the subscription limit, but the error itself turned out to be unrelated to their entitlement, and it cleared up within a day. While we were looking, I asked whether they could clear the plug-in traces in that environment and switch the trace level from All to Exceptions. Their developers had been toggling it back and forth. They agreed to keep it at Exceptions and only use All when actively debugging.
Two lessons from that. First, an error that mentions disk space isn't necessarily about your capacity entitlement. Open a support case and keep reproducing details. Second, trace settings drift in development environments because many people can change them.
How I'd handle it today
- Keep tracing Off in production unless you're actively troubleshooting, and turn it off when you're done. That's Microsoft's own guidance.
- Know the built-in safety net. A daily background job deletes trace records older than 24 hours. Don't disable it or change its frequency without a plan to put it back.
- Check the setting in every non-production environment during your monthly review, not just production.
04System jobs (AsyncOperation)
Every asynchronous workflow, async plug-in and background operation creates a record in the System Job table (AsyncOperationBase), and workflow logs go to WorkflowLogBase. If a workflow fires on every update, or a plug-in fails repeatedly, these tables can grow faster than anything else in the database.
The same genomics company emailed me in late 2020: tens of gigabytes of new system jobs had appeared in production within a single week, and they couldn't see why. A few months later the pattern repeated. Their own investigation pointed to a large number of failed jobs that were never being deleted. The cleanup helped, but the bigger lever was already in flight: a project to move email attachments out of Dynamics, which they expected to free far more space than any system job cleanup.
How I'd handle it today
- Confirm the deletion service is on. By default it removes succeeded jobs after 30 days and failed or canceled jobs after 60. You can change those periods from the environment's Audit and logs settings (the page was in preview when I last checked) or through database settings.
- Find the noisy process. Group system jobs by name and status. One misbehaving workflow usually explains most of the growth.
- Fix the design, not just the data. For classic workflows, turn on automatic deletion of completed workflow jobs, and filter triggers so a process doesn't run on every field change.
- Test bulk deletes in a sandbox. Microsoft warns that deleting AsyncOperation records also deletes the related file records, and they can't be recovered.
05Attachments and email
Attachments count against File capacity, and in many of the environments I reviewed they were the single largest consumer. Microsoft documents several ways to reduce them, including finding emails with large attachments and running bulk deletion jobs that recur on a schedule.
By mid-2021 the same customer told me directly that storage cost was their main concern, and they were already moving attachments out of Dynamics. I think that was the right call. A few points I'd add today:
- Deleting attachments removes them from the app. If users saved them in Outlook, those copies remain.
- Moving files elsewhere is a File-capacity decision. It won't fix a Database shortfall.
- Reduce new volume too. Mailbox tracking settings decide how much email, and how many attachments, come in every day. My activity growth post covers the tracking filters in detail.
06Then vs. now at a glance
| Culprit | Meter | What we did in 2020 | What I'd do in 2026 |
|---|---|---|---|
| Audit logs | Log | Delete the oldest partition repeatedly, or ask for help clearing lower environments | Set retention from the Security page; delete by table, access logs or date |
| Plug-in traces | Log | Clear traces, switch All to Exceptions | Off in production; rely on the 24-hour cleanup job; review non-prod monthly |
| System jobs | Database (+ File) | Find failed jobs, bulk delete, fix the workflow | Confirm the deletion service and its retention; same root-cause work |
| Attachments | File | Project to move files out of Dynamics | Bulk delete old attachments, move documents, tighten tracking |
| Visibility | All | Ask someone to run a report | Per-table capacity view and export in the admin center; capacity alerts |
07A housekeeping routine that sticks
In August 2021 I recommended a Dataverse storage capacity assessment to that genomics customer. The goal was a full review of every environment in the tenant, the key areas for reduction, and maintenance practices that would keep them there. The assessment was useful, but the routine afterward mattered more. Here's the version I'd use now:
Look
- Export capacity by table for every environment
- Compare against last month on the same basis
- Check trace settings in non-prod
Tune
- Review audit scope and retention with compliance
- Review system job retention and noisy processes
- Retire environments nobody owns
Plan
- Forecast growth by meter
- Agree retention windows with the business
- Decide what to buy versus what to clean
In early 2023 a customer saw database capacity jump with no obvious cause. My first request was the same as it would have been in 2020: export all tables from the capacity report so we could see actual utilization. The export showed growth in contacts, addresses and activities starting on a specific date, which pointed to a data load rather than a platform problem. I also suggested opening a support case in parallel, in case a recent release was involved. That's the moment the story moves from housekeeping to activity growth, which is where my 2026 follow-up picks up.
Where I'd start
Open the capacity report, export the per-table view for every environment, and look at the Log meter first. Set an audit retention period that compliance has approved, confirm tracing is off in production, and check that the system job deletion service is on. Then name an owner for every environment that consumes capacity. Most of the storage emergencies I worked on in 2020 would have been routine maintenance with those four things in place.
Happy to go deeper on any of this.
— K.G
→ Next: "Your Dataverse Storage Is Growing Fast? Look at Activities First"
Related: Environment strategy and DLP for keeping environment sprawl under control, and the 2026 governance toolbox for monitoring.
Sources
- Microsoft Learn: Manage Dataverse auditing
- Microsoft Learn: Recover database space by deleting audit logs
- Microsoft Learn: Logging and tracing (Microsoft Dataverse)
- Microsoft Learn: Delete completed system jobs and process log to comply with retention policy
- Microsoft Learn: AsyncOperationBase table storage
- Microsoft Learn: Free up storage space
- Microsoft Learn: Dataverse capacity-based storage details
Get new posts by email
Provider: your email provider
