Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Finance and operations apps in unified environments use elastic compute to provide flexible and scalable compute power. Instead of selecting a fixed-size environment tier at purchase time, all your sandbox and production environments draw from a shared capacity pool and automatically scale based on actual usage.
This means:
- Sandbox and production environments use the same performance model. Performance testing in a sandbox environment reflects what you can expect in a production environment—no more guessing across tiers.
- You don't pick a tier. Your compute capacity is determined by your Power Platform Request (PPR) entitlement and scales automatically.
- Adding capacity is simple. Purchase more PPRs to increase your compute ceiling, or add storage to create more environments—no contract amendments or support tickets required.
How elastic compute works
In unified environments, the Application Object Server (AOS) tier is the primary compute component for finance and operations apps. Each AOS instance hosts X++ business logic and handles user requests, OData and custom service calls, integration traffic, and batch workloads.
AOS instances are stateful and hold user session state in memory. Internal Azure load balancers distribute requests across AOS instances, and session affinity ensures that a user's requests go to the same AOS instance during their session. The environment stores persistent data such as metadata and transactional state externally in Azure SQL, caching layers, and blob storage.
Because AOS instances hold session state in memory, scaling up and scaling down behave differently. Adding new AOS instances (scale-up) is seamless and doesn't disrupt active users. However, removing AOS instances (scale-down) requires draining active sessions, so it's reserved for planned maintenance windows or customization deployments, where a natural downtime already occurs. This approach ensures that users never experience unexpected session loss due to a scale-down event.
An environment supports a maximum of 80 AOS instances total, split between up to 40 interactive AOS instances that serve user requests and up to 40 batch processor AOS instances that handle background jobs.
Deploy to the middle
When Microsoft provisions a finance and operations environment, it deploys to a mid-sized baseline topology. This baseline is:
- Not the minimum compute available for the environment.
- Not the maximum compute available for the environment.
- Chosen to handle steady-state interactive usage, normal batch processing, and typical Dataverse and Power Platform integration patterns.
By starting in the middle, the platform minimizes the need for cold-start scaling events. Most customer workloads oscillate around this baseline, so the environment is ready for typical usage immediately after provisioning.
Scale up
When the platform detects increased demand, it scales up from the baseline. Scale-up can be triggered by:
- High concurrent interactive user sessions
- Burst API traffic from OData or custom services
- Heavy batch job processing
- Increased Power Platform-initiated calls through Dataverse virtual tables
During scale-up, the platform adds more AOS instances horizontally and redistributes the load across them. Batch capacity can also increase independently. Scale-up happens with no downtime and is transparent to active users.
Scale down
Because AOS instances hold session state in memory, scale-down can't happen on demand without risking disruption to active users. Instead, the platform reserves scale-down for planned maintenance windows or when you deploy customizations, both of which involve a natural downtime period. During these windows, the platform drains and removes extra AOS instances, and the environment returns to its baseline topology.
The environment scales down to the baseline, not below it. This approach ensures that the environment is always ready for normal workloads when it comes back online.
Power Platform requests and compute capacity
Power Platform Requests (PPRs) govern compute capacity for finance and operations apps in unified environments. PPRs serve as the unit of measure for how much compute power is allocated to your environments.
How PPRs translate to AOS capacity
Each AOS instance requires 650,000 PPRs of capacity. The more PPRs your tenant has available, the more AOS instances the platform can allocate across your environments, and the more room there is for elastic scaling.
How you accrue PPRs
You accrue PPRs to your tenant in three ways:
| Source | Amount | Details |
|---|---|---|
| Tenant-wide base | 500,000 PPRs | Automatically included with any Dynamics 365 purchase. |
| Per-user license accrual | 5,000 PPRs per license | Each assigned user license contributes to the tenant's total PPR pool. |
| Add-on packs | 50,000 PPRs per pack | Purchased from the Microsoft 365 admin center. |
Minimum and maximum AOS
Every sandbox and production environment is provisioned with a minimum of two AOS instances (one interactive, one batch) regardless of available PPRs. This configuration ensures the environment is functional and provides basic redundancy. The maximum is 80 AOS instances (40 interactive, 40 batch).
Example: PPRs and AOS capacity at different scales
The following table shows how PPRs accrue and translate to AOS capacity across a range of customer sizes. Each row includes only licenses and the tenant-wide base. Add-on packs can increase the total further.
| User licenses | PPRs calculation | Total PPRs | AOS capacity |
|---|---|---|---|
| 20 (minimum) | 500,000 + (20 × 5,000) | 600,000 | 2 AOS (floor) |
| 100 | 500,000 + (100 × 5,000) | 1,000,000 | 2 AOS |
| 250 | 500,000 + (250 × 5,000) | 1,750,000 | 2 AOS |
| 500 | 500,000 + (500 × 5,000) | 3,000,000 | 4 AOS |
| 1,000 | 500,000 + (1,000 × 5,000) | 5,500,000 | 8 AOS |
| 2,500 | 500,000 + (2,500 × 5,000) | 13,000,000 | 20 AOS |
| 5,000 | 500,000 + (5,000 × 5,000) | 25,500,000 | 39 AOS |
| 10,000+ | 500,000 + (10,000 × 5,000) | 50,500,000 | 77 AOS |
If the PPRs formula yields fewer than two AOS instances, the environment receives the two AOS instances as a minimum. If it yields more than 80, the environment is capped at 80.
Increasing capacity with add-on packs
If your license-based PPRs don't provide enough AOS capacity, you can purchase add-on packs of 50,000 PPRs each from the Microsoft 365 admin center. For example, a customer with 20 licenses (600,000 PPRs) could purchase 40 add-on packs (two million PPRs) to reach 2,600,000 total PPRs—enough for two more AOS instances, which combined with the two AOS minimum gives four AOS instances total. This would be added as a maximum allowed number of AOS instances to every environment created now and in the future. The number of environments is limited by having available storage.
These totals determine the compute capacity available for elastic scaling across all finance and operations environments in the tenant.
PPRs serve two purposes
PPRs play two distinct roles, and it's important to understand both roles:
- Capacity entitlement. PPRs determine how many AOS instances your environments can scale to, as described in this article.
- Request throttling limit. PPRs also govern throttling limits for Power Platform operations such as Dataverse calls, plug-ins, and flows.
These roles are related but independent. Purchasing more PPRs increases your AOS compute ceiling and raises your Power Platform request limits. However, heavy Dataverse traffic through virtual tables into finance and operations apps can trigger elastic scale-up to handle the load, even though the request limits themselves are a separate mechanism.
Unified developer environments
Unified developer environments (UDE) are an exception to elastic compute scaling. While sandbox and production environments have a minimum of two AOS instances, UDE environments are limited to a minimum and maximum of one AOS instance and don't scale up or down. This limitation exists because of technical constraints with the Visual Studio debugger, which must attach to a specific AOS process. A single AOS instance ensures that the debugging experience remains stable and predictable.
For development and testing workloads that require multiple AOS instances, use a sandbox environment instead.
Key differences from Lifecycle Services
In Lifecycle Services, you tied environments to fixed tiers and purchased them as individual slots. This model created friction in three areas:
- Tier lock-in. Sandbox environments came in fixed tiers (Tier 2–5), each with progressively more compute. You selected a tier at purchase time through your Enterprise Agreement or cloud solution provider, and changing tiers later required contract amendments.
- Sandbox/production performance gap. Production environments had different tiers and compute profiles than sandbox environments. Performance testing in a tier 2 sandbox couldn't reliably predict production behavior, because the underlying resources didn't match.
- Scaling required support. To get more compute within a tier, you had to open support tickets and escalate them. To get a second production environment, you needed to create a new Lifecycle Services project with a separate license minimum.
In unified environments, you eliminate these constraints. All sandbox and production environments draw from the same PPR-based capacity pool. Performance testing in a sandbox environment reflects what you can expect in production, because both environment types share the same elastic compute model and maximum scale.
The following table summarizes the key differences.
| Aspect | Lifecycle Services | Unified environments |
|---|---|---|
| Compute model | Fixed tiers selected at purchase time | Elastic, scales automatically based on PPR |
| Sandbox = production? | No—different tiers, different SQL, different AOS counts | Yes—same capacity model and maximum scale |
| Changing capacity | EA/CSP contract amendments or support tickets | Purchase PPR add-on packs from the Microsoft 365 admin center |
| Scaling behavior | Manual tier change with downtime | Automatic scale-up (no downtime), scale-down during maintenance |
| Creating environments | Purchase addon slots per tier | Available storage (1 GB required) |
| Multiple production environments | Required a new Lifecycle Services project | Provision directly from the tenant capacity pool |
| Performance testing reliability | Sandbox tier mismatch made results unreliable | Sandbox and production share the same compute ceiling |
| Maximum AOS per environment | Varied by tier (3–12 AOS) | Up to 80 AOS instances (40 interactive + 40 batch) |
| Developer environments | Cloud-hosted Azure virtual machines | Unified developer environments with single AOS instance |