Dataverse capacity on a Field Service tenant

What it does

Dataverse storage is licensed as three separate tenant-wide pools — Database, File and Log — made up of a default allowance plus capacity that accrues from the Dynamics 365 and Power Platform licences you own. Field Service is one of the heavier consumers of all three, and capacity is the thing that quietly blocks environment operations at the worst moment.

Key facts

Three pools, and they are not interchangeable at purchase: Database (table data and metadata), File (attachments, notes and file/image columns) and Log (audit data, plug-in trace logs and elastic tables).
The default tenant allowance is 3 GB Database, 3 GB File and 1 GB Log. That sits with the default environment and doesn't count against purchased capacity.
Capacity accrues per user licence purchased for Dynamics 365 enterprise applications. Learn deliberately does not publish the per-licence GB figures — they're in the Power Platform Licensing Guide, and they've changed more than once. Read the tenant's actual entitlement rather than quoting a number from memory.
Where to look: Power Platform admin centre > Licensing > Capacity add-ons for the tenant summary, and the Dataverse tab for the per-environment breakdown.
Enforcement is soft. Overage generates email notifications at 15% remaining, at 5% remaining, and again when you exceed capacity after borrowing has been applied. Nothing stops writing.
Borrowing between pools is one-directional: Database can cover Log or File overage, and Log can cover File. File covers nothing.
What does get blocked is environment lifecycle work, when the underlying capacity type has less than 1 GB available: creating an environment, copying or restoring one, converting a trial to paid, recovering an environment, and adding a Dataverse database.
Add-on capacity is purchasable per pool through normal procurement channels.

When to use / skip

This is not optional reading on any Field Service delivery. Field deployments generate storage in patterns that a Sales or Customer Service project never sees: inspection attachments and job photos from the mobile app land in File, booking timestamps and geolocation traffic land in Database, and if the client turns on auditing broadly — which service organisations tend to, for SLA and dispute reasons — Log grows continuously.

You can skip the deep capacity modelling on a small pilot with a few dozen technicians and no photo capture. You cannot skip it on anything with a mobile workforce taking pictures. Do a per-work-order storage estimate during design: attachments per job, average size, jobs per day, retention period. That arithmetic decides whether the client buys add-on File capacity or builds an offload to SharePoint or Azure Blob.

Configuration decisions

Whether job photos and inspection attachments stay in Dataverse File storage or are offloaded to SharePoint or Azure Blob. This is much cheaper to decide before go-live than after.
Which tables are audited and for how long. Audit retention is a Dataverse setting and it is the main lever on the Log pool.
Retention and bulk-delete jobs for the high-volume Field Service tables — booking timestamps, booking journals, IoT alerts and system job records all accumulate.
Whether non-production environments live on the same tenant capacity, and how many sandboxes the programme really needs. Every copy consumes the same pools.
Who owns the capacity notifications, and whether they go anywhere other than a global admin's ignored mailbox.
Whether you buy add-on capacity per pool up front, or run close and react.

Gotchas

The 1 GB free-space rule on lifecycle operations is the one that ruins a weekend. A capacity-starved tenant will refuse to restore an environment or convert a trial to paid, and the error rarely says "capacity" in words anyone reads first.
File capacity is the one that fills, and it is the one pool that nothing can lend to. Database and Log can bail out File; File can't be bailed out of anything else.
Copying production to a sandbox duplicates the storage. Programmes that refresh three sandboxes from a large production database find out about capacity from the failure, not from the plan.
Elastic tables count against Log, not Database. That surprises people who use them precisely because they expected them to be cheap.
Turning auditing on across all tables "so we have it if we need it" is a permanent recurring cost, not a one-off. Field Service's high-churn tables make it worse.
Capacity accrues from licences purchased, so trimming a licence count at renewal also trims the entitlement. That can push a tenant into overage without anybody touching data.

Consultant notes

Pull the Capacity page in Power Platform admin centre on day one of any engagement and screenshot it. Knowing the starting position saves an argument later about who filled the tenant.
Give the client the storage arithmetic in their own numbers — jobs per day, photos per job, megabytes per photo — rather than a generic warning. It's the only version that gets budget approved.
Push back on unbounded audit configuration. Ask which tables the business would genuinely need to reconstruct, and audit those.
Before go-live, check there's at least a comfortable margin in every pool, specifically so restore and copy operations are available if something goes wrong in the first week.
Say plainly that the per-licence capacity accrual figures are licensing guide material and change between guide releases. Never repeat a figure from an old deck.

Worth revisiting when the Power Platform Licensing Guide is refreshed, or if Microsoft changes how File capacity is allocated.