Your Dataverse Storage Is Growing Fast? Look at Activities First

By Kaustubh Giri, Sr Solution Engineer. ~12 min read.

A question I’ve been getting a lot lately is: “Our Dataverse storage keeps climbing and we’re getting overage warnings. Do we buy more capacity, or start deleting?” My honest answer is that you can’t make that call until you know what’s growing. And in most Dynamics 365 environments I look at, the first answer is activities.

That isn’t a bad thing. Activities are the history of your customer relationships. But that history grows every day, and a few settings can make it grow much faster than the business needs. Here’s how storage is measured, how to find what’s consuming it, which levers work, and how I’d frame it for leadership.

A quick caveat: Capacity reporting and overage enforcement in the Power Platform admin center have been changing through 2026, and some of what I describe (like the Dataverse storage advisor) is still rolling out or in preview. Check current docs on Microsoft Learn before you act on any specific threshold or timeline.

In this post:

1. Three meters, not one
2. Find what’s actually growing
3. Why activity tables grow
4. Email tracking: capture less
5. Bulk deletion: decide what goes
6. Long-term retention and its limits
7. Log and system housekeeping
8. Decision table
9. Talking to executives
10. A 30-day plan

1. Three meters, not one

This is a common point of confusion. Dataverse doesn’t have one storage number. It has three capacity types, and each one is entitled, consumed, and enforced on its own terms.

• Database - Rows, metadata, indexes - Most tables, including ActivityPointerBase. Indexes count here too, and so does the Dataverse search index (reported as a table called DataverseSearch).
• File - Attachments and files - Email attachments, note attachments, file and image columns. The database still keeps a few columns needed to find each file.
• Log - Audit and tracing - AuditBase, PlugInTraceLogBase, and elastic tables. Log entitlement is tracked separately for Dataverse.

The part that matters most for planning is borrowing. Spare capacity can only flow downhill: Database can cover a Log or File shortfall, and Log can cover File. File can never cover Database or Log, and nothing can cover a Database deficit. So a large File surplus looks reassuring on a slide but doesn’t help you if Database is the problem.

Why this matters: If your Log is over its own entitlement, Database is quietly absorbing it. Every GB of new activity history then eats into the same headroom that’s covering Log. That’s why I always tell customers to plan Database and Log together.

Overages have real consequences. Once a tenant exceeds its effective capacity, environment create, copy, restore, and recover operations are blocked. Under the newer storage validation experience, affected sandboxes without pay-as-you-go can later move to administration mode and then be disabled. Production is excluded from that path. Check the rollout status for your tenant.

2. Find what’s actually growing

Before anyone proposes a cleanup, get the facts from the Power Platform admin center. Here’s how I approach it:

1. Licensing -> Dataverse. Look at usage per storage type, prepaid versus pay-as-you-go, and the top environments consuming storage.
2. Drill into the environment. The consumption-per-table view shows each table’s size for Database, File, or Log, and you can open a daily trend for up to three months.
3. Download all tables. Export the full list. The on-screen grid only shows the top entries.
4. Check the storage advisor. Where it has rolled out, the Dataverse storage advisor (preview) adds a cleanup estimate per table and can turn a recommendation into a retention policy or a bulk delete.
5. Set alerts. When you allocate capacity to an environment, you can opt in to daily email alerts at a percentage you choose.

The report isn’t real time. It can take up to 72 hours to reflect a deletion, and deleting 10 MB doesn’t necessarily free 10 MB. Compare like-for-like snapshots before you declare victory.

From the field: A software company in the education space came to us wanting to move off Dataverse entirely to cut costs. They had close to a terabyte of database. Archiving and long-term retention were the first suggestions on the table, and those are normal, sensible answers. My question back was: is that practical before we know what’s really driving the usage? We needed the per-table breakdown and the growth trend first. At this point any remedy was only a hypothesis.

3. Why activity tables grow

Every activity, whatever its type, gets one row in ActivityPointerBase. That row holds the common columns: subject, owner, regarding, status, and the description. For an email, the description is the email body, so large HTML emails make this table grow quickly. Participants live in ActivityPartyBase, attachments live in the attachment tables, and type-specific columns live in their own extension tables.

So when someone compares a 60 GB ActivityPointer table with a 9 GB Email table and concludes that emails are being duplicated, I’d temper that. ActivityPointer holds the shared row for every activity type, not just email. Size alone isn’t evidence of duplicate or unnecessary data.

Table	Meter	What drives it
ActivityPointerBase	Database	Volume of all activity types, plus email bodies held in the description column. Views that include the description column also grow its index.
ActivityPartyBase	Database	Senders, recipients, and attendees for each activity. Long distribution lists add up.
Attachment / ActivityMimeAttachment	File (+ some Database)	Email attachments, stored as file blobs. A reused file isn’t stored twice.
AsyncOperationBase, WorkflowLogBase	Database (+ File)	System jobs and workflow logs, including async plug-ins and bulk email.
AuditBase, PlugInTraceLogBase	Log	Auditing scope and retention, and plug-in trace settings.

There’s one automatic relief valve. Email bodies older than twelve months move to blob storage, in a job that runs roughly every 30 to 60 days per tenant. Database goes down and File goes up. If you went live recently, don’t expect near-term relief from this.

From the field: A financial services firm running a contact center saw ActivityPointer become its largest production table by a wide margin. The first assumption was duplicate emails. But just over half of the activity rows weren’t email at all: sessions, conversations, and case resolutions. A UAT test showed one inbound email legitimately creating three activities (an email, a conversation, and a session). That’s three real interaction types, not duplication. The real questions were how fast, how long to keep it, and what else was adding avoidable volume.

4. Email tracking: capture less

When I reviewed one customer’s situation, my first recommendation was to tighten server-side synchronization. The question I asked was simple: are you tracking every incoming email, or only email related to your customers? That one setting decides how many activities you create every day.

Each user and queue mailbox has an incoming email filter:

Option	What gets tracked	Volume
All email messages	Everything the user or queue receives	Highest
Email messages from records that are email enabled	Anything that resolves to an email-enabled record, including custom tables	Medium
Email messages from Leads, Contacts, and Accounts	Only mail that resolves to a known customer record	Lower
Email messages in response to email (default)	Only replies to messages already tracked	Lower
No email messages	Nothing automatic	Lowest

A few other settings matter too:

• Queues set to “All email messages.” A shared support mailbox on this setting is usually the single biggest source of tracked email. Make sure it’s a deliberate choice.
• Folder-level tracking. Users move messages into a tracked Exchange folder, which gives you accurate, intentional tracking instead of broad automatic capture. Manual tracking like this works regardless of the user’s automatic filter.
• Tracking between Dynamics 365 users. By default, an email between two users creates two activities, one for each. Turning that off reduces internal volume. It doesn’t change how external email routed to several queues is handled.
• Attachments. Tracked email brings its attachments along, and they count against File. I treat moving them to SharePoint as a File-capacity decision, not a fix for a Database deficit.

What I recommend: Change filters one group at a time and measure. A tighter filter reduces future growth; it does nothing for the history you already have. And confirm with the business that agents don’t rely on broad capture to see the full customer conversation before you change a queue.

5. Bulk deletion: decide what goes

For history the business no longer needs, a recurring bulk deletion job is usually the largest single source of recovered space. I typically suggest starting the conversation at completed activities older than 12 to 18 months, but that window is a business and compliance decision, not mine.

Be clear about two things. Deletion is permanent; activities disappear from the timeline. And Microsoft’s own guidance notes that buying capacity can make more sense than deleting, partly because every deletion should be tested in a sandbox first. I don’t see a contradiction: buy time with capacity, then delete what you’ve agreed to delete.

• Build the job on a tested view, with criteria like status, Actual End older than X months, and activity type.
• Run it off-hours and on a schedule, so it keeps pace with new growth.
• Remove activity views that include the description column; they enlarge the table’s index.
• If you use unified routing diagnostics in Customer Service, keep it off in production. Microsoft has deprecated the feature, its data uses database capacity, and old diagnostic records can be bulk deleted.

6. Long-term retention and its limits

Dataverse long-term retention (LTR) moves inactive rows into a compressed, read-only store inside Dataverse. Microsoft says each retained GB uses on average about 50% less database capacity, with results varying by data. It doesn’t require a separate purchase. It’s a good fit for history you must keep but rarely open. It also has constraints I always walk through before anyone counts on savings:

• You can’t target ActivityPointer, ActivityParty, or Attachment directly. Activities are retained as children of an eligible parent table, such as a closed case.
• It’s one-way. Retained data can’t be moved back to active. It’s read-only and available through Advanced Find, flows, and the API.
• It requires a Managed Environment. Otherwise the policies are disabled.
• Retained data still counts. Reports show Table and Table-Retained entries. File attachments see no meaningful File savings.
• It isn’t instant. A policy run takes 72 to 96 hours, plus reporting lag; savings can take up to two weeks to show in non-production.

I’d pilot one parent table in a sandbox, confirm what users can still see, and only then schedule it in production.

7. Log and system housekeeping

Activities are usually the biggest Database story, but the Log meter and system tables often hide easy wins.

Audit retention

Generally available · PPAC -> Security -> Compliance -> Auditing

Audit logs consume Log capacity, and the default retention is Forever. Set a retention period that matches your policy; setting it from the Security page can also apply it to existing logs. You can delete old logs by table, access type, or date.

System jobs (AsyncOperation)

Generally available · PPAC -> Settings -> Audit and logs

A deletion service removes completed jobs by default: succeeded after 30 days, failed and canceled after 60. Confirm it’s on. For classic workflows, turn on “Automatically delete completed workflow jobs”.

Plug-in trace logs

Generally available · System settings -> Plug-in trace log setting

A daily job deletes trace records older than one day. Microsoft recommends keeping tracing Off in production. If a non-production environment shows far more trace rows than production, check the setting and whether the cleanup job is healthy before assuming a defect. A row count alone doesn’t tell you how many GB it represents.

Power Automate run history

Check your report · PPAC -> Settings -> Product -> Features

Solution cloud flows write run history to the FlowRun elastic table, kept for 28 days by default. You can lower it to 14 or 7 days, or turn it off. One caution: the Power Automate article says FlowRun uses database capacity, while the capacity article lists elastic tables under Log. Check which meter it appears under in your own report.

From the field: For the financial services firm, Log had passed its own entitlement and was being covered by spare Database capacity. Their UAT environment showed many thousands of plug-in trace rows, while production had only a handful. That was a lead, not a conclusion. We agreed to measure GB, record age, the trace setting, and cleanup job health before changing anything.

8. Decision table

What you see	Meter	Lever	Reversible?	Who signs off
ActivityPointer growing with email volume	Database	Tighten mailbox and queue filters; folder-level tracking	Yes	Business owner
Years of completed activities nobody opens	Database	Recurring bulk delete on an agreed window	No	Business + compliance
Old history you must keep	Database	LTR on an eligible parent table	One-way	Compliance
Large attachments	File	Bulk delete old attachments, or move to document storage	No	Business owner
Audit logs kept forever	Log	Set audit retention; delete old logs	No	Compliance / security
Plug-in traces in prod	Log	Tracing Off; verify cleanup job	Yes	Platform team
AsyncOperation / WorkflowLog large	Database	Deletion service, workflow auto-delete settings	No	Platform team
Flow run history	Check report	Lower FlowRun time to live	Yes	Platform team
Real deficit while work is under way	Any	Buy the right capacity type, pay-as-you-go, or a temporary extension	Yes	Finance + IT leadership

9. Talking to executives

Executives need three things: why storage grows, what doing nothing costs, and what decisions you need from them.

The goal is predictable storage, not zero growth.

Here’s the framing I use:

• Growth is expected. Every customer interaction creates history. The question is whether it’s efficient.
• Compare two costs. Capacity is a known monthly cost you can quote today. Cleanup is people’s time, testing, and risk, and it takes weeks to show up in the reports. Most of the time you need some of both.
• Size capacity honestly. Microsoft Learn’s formula is a good anchor: required capacity equals the effective deficit, plus expected growth, plus an operating buffer, minus cleanup that’s confirmed but not yet reported. And buy the type you’re short of; File can’t fix Database.
• Ask for three decisions. Who approves retention, which history must stay readily available, and authorization for a bounded pilot plus a capacity buffer.

What I’d avoid: Don’t promise a percentage saving or a flat line. Don’t turn an illustrative run rate into a countdown clock. And don’t present an old headroom figure as today’s. Reconcile the numbers in the admin center first, on one snapshot, and say what still needs validation.

If storage is part of a broader conversation about environment sprawl, my environment strategy and DLP post covers the environment side, and the governance toolbox guide covers monitoring.

10. A 30-day plan

Days 1-7: Baseline and protect

• Export capacity by type, environment, and table on one date
• Confirm effective deficit after borrowing
• Agree a capacity buffer or pay-as-you-go so operations aren’t blocked
• Name owners for headroom, Log, capture, and retention

Days 8-20: Quick, low-risk wins

• Review queue and mailbox tracking filters
• Set audit retention; tracing Off in prod
• Confirm system job cleanup and FlowRun time to live
• Remove description from activity views
• Draft retention windows with business and compliance

Days 21-30: Pilot and measure

• Test a bulk delete or LTR policy in a sandbox
• Validate what users can still see
• Compare before and after GB on the same basis
• Bring results and a capacity forecast to leadership

Success means required history is protected, net growth is slower on comparable evidence, and you have an agreed buffer and review trigger. Continuing growth isn’t failure.

Where I’d start

Open the per-table capacity report and find your top five tables by GB across Database and Log. If ActivityPointer is at the top, check queue and mailbox tracking filters before anything else, because that decides how fast it grows from tomorrow. Then protect your headroom, agree retention with the business, and pilot cleanup in a sandbox. Capacity buys time; retention discipline keeps you out of the same conversation next year.

Happy to go deeper on any of this.

K.G.

Sources

• Microsoft Learn: Dataverse capacity-based storage details
• Microsoft Learn: ActivityPointerBase table storage; Activities data model and storage
• Microsoft Learn: Free up storage space
• Microsoft Learn: Email activity tables (email storage and transition period)
• Microsoft Learn: Specify which emails are automatically tracked; Manage email tracking settings
• Microsoft Learn: Dataverse long term data retention overview; Set a data retention policy for a table
• Microsoft Learn: Manage Dataverse auditing
• Microsoft Learn: Delete completed system jobs and process log to comply with retention policy
• Microsoft Learn: Manage cloud flow run history in Dataverse
• Microsoft Learn: Manage routing diagnostics data (Dynamics 365 Customer Service)

---

Product details and statuses reflect publicly available information as of October 2026. Preview features may change. Customer examples are anonymized.

Get new posts by email

Email addressSubscribe

Provider: your email provider