Capacity planning for Dynamics 365

Capacity planning is the unglamorous side of Dynamics 365 operations. Done well, it prevents the surprise emails ("you've exceeded your storage allowance and Microsoft will start billing overages next month") that nobody wants. Done badly, it forces emergency licence purchases at the worst possible time. Three resources dominate: Dataverse storage, API call volume, and AI Builder credits.

Dataverse storage. The most-watched capacity metric. Dataverse storage is split into three tiers:

• Database — the relational store. Most expensive. Holds the transactional data and indexes. Allocated per tenant based on licences; per-user Dynamics 365 SKUs add a small amount each.
• File — attachments, images, file columns. Cheaper. SharePoint document storage (for documents on records) is separate and not counted here.
• Log — audit logs, plug-in trace logs, change history. Cheapest.

Watching consumption. The Power Platform admin centre shows usage per environment over time. Trending matters more than current value — what's growing at 50 GB/month and what's stable? Common growth drivers:

• Email tracking (each tracked email is a Dataverse record with full content).
• Plug-in trace logs (enable verbose tracing temporarily for debug, forget to disable, grow rapidly).
• Audit history on high-volume tables.
• Notes and attachments stored in Dataverse rather than SharePoint.

Lowering Dataverse consumption.

• Move documents to SharePoint for record attachments. SharePoint storage is generous in M365 licences; Dataverse File storage is not.
• Bulk-delete old audit history beyond the retention requirement.
• Disable plug-in trace logging in production except when debugging.
• Archive old data to OneLake via Synapse Link, then bulk-delete from Dataverse.

API call capacity. Dataverse, Business Central, and Finance/SCM all have per-tenant API call limits, generally generous but real. Power Automate flows, integrations, and custom apps all count toward the limit. Heavy integration tenants can hit it.

Watching API consumption. The admin centre shows API request volumes per user and per environment. The most common surprise: a Power Automate flow that started running 1,000× per hour because of a misconfigured trigger.

Lowering API consumption.

• Filter at the trigger so flows only fire on relevant changes.
• Batch operations rather than calling per row.
• Cache read-heavy lookups instead of fetching every time.
• Use webhooks or Service Bus integration instead of polling.

AI Builder credits. AI Builder runs on a credit model — each invocation consumes credits. Tenants get an allocation per licence and per add-on. Credit consumption grows with document automation, prediction models, and AI-powered actions. Monitor monthly; budget against expected automation volume.

Environments as a capacity unit. Each environment counts against tenant resources. Sandboxes are mostly free up to a cap; production environments cost.

Forecasting growth. Project capacity 12–24 months ahead:

• New users → more storage and more API calls.
• New integrations → more API calls.
• New features → more storage and Power Automate runs.
• Acquisition or organic growth → step-changes in volume.

The annual review. Once a year, look at capacity vs licence allocation, project the next 12 months, and either buy capacity add-ons proactively or implement reduction work (archive, delete, deprecate). Don't wait for the over-limit alert.

Common patterns.

• First-year over-provision by buying generous storage add-ons "just in case" — usually unnecessary.
• Third-year crisis when audit history and email tracking have eaten through the original allocation — proactive cleanup avoids.
• Sudden integration overrun when a poorly-designed flow burns API quota — daily monitoring catches early.

Operational reality. Capacity planning is 30 minutes a month of admin review and 4 hours a year of forecasting. Worth it.