Dynamics 365 FSCM: New PPR Capacity Model and Elastic Compute

From fixed LCS tiers to elastic compute powered by Power Platform Requests (PPR)

The question is no longer “Which tier do we need?”
It is “How much PPR capacity is available, and is it enough for our workload?”

Executive Summary

Microsoft is changing how Dynamics 365 Finance & Operations environments are sized and managed. The traditional model based on predefined LCS tiers is being replaced by a unified model administered through Power Platform Admin Center (PPAC). Capacity is driven by Power Platform Requests (PPR), creating a direct link between licensing, tenant consumption and available compute resources.

Key Takeaways

1. From Fixed Tiers to Unified Environments

Historically, environment planning in Lifecycle Services required customers to select a predefined infrastructure tier. Each tier provided a fixed resource envelope based on anticipated transaction volumes and concurrent users. In the unified model, Microsoft replaces fixed sizing with elastic capacity that adapts to workload demand and available entitlement.

2. How the New Capacity Model Works

The model revolves around Power Platform Requests, which contribute to the capacity pool available to the tenant.

Worked Example

Base tenant	500,000 PPR
200 assigned licences	1,000,000 PPR
2 additional packs	100,000 PPR
Total	1,600,000 PPR

Using assumption of 650,000 PPR per AOS, this example is presented as approximately three AOS instances. The calculation should be treated as an indicative sizing view and validated against the applicable licensing and capacity rules.

3. Why Elastic Compute Changes the Game

IMPORTANT  Elasticity does not replace application optimisation, integration design, batch management or operational monitoring.

4. Impacts for Solution Architects and Project Teams

Environment planning becomes less focused on selecting a predefined infrastructure tier and more focused on monitoring available PPR capacity. Capacity management therefore becomes an architectural concern, particularly for organizations with complex integrations, high transaction volumes, or seasonal workload peaks.

Sandbox and production environments use the same general elastic compute model. This can help performance testing results better reflect production behaviour, provided that test data volumes, batch workloads, integrations and user scenarios are representative.

Environment strategy must now be considered at tenant level. The design discussion needs to connect capacity entitlement, storage growth, integration workloads, batch processing, performance testing and environment lifecycle decisions.

Capacity governance	Monitor tenant-level PPR entitlement and consumption.
Performance engineering	Use realistic data volumes, batch workloads and user scenarios.
Integration design	Control chatty interfaces and peak request patterns.
Environment lifecycle	Assign an owner, purpose and review date to every environment.
Commercial alignment	Treat licensing and add-on capacity as architecture inputs.

Conclusion

The most important shift is conceptual. Environment sizing is no longer primarily an infrastructure decision. It becomes a capacity management and governance discipline. Organizations that understand and monitor their PPR consumption will be better positioned to optimize costs, scale efficiently and benefit from the unified Dynamics 365 architecture.

Licensing strategy, capacity planning and infrastructure sizing are now closely connected, and the shared pool should be governed at tenant level alongside actual consumption, performance monitoring and environment lifecycle management.