If your apps or flows have ever stopped working without warning, there’s a good chance request limits were the culprit.

In Power Platform, every time a user saves a record, triggers a flow, or calls a connector, it counts as a request. Individually, these seem small. But as usage grows, so does the number of requests, and eventually, you’ll hit your limit.

As a result, bandwidth control kicks in, you get notified of failed runs or denied access that seem to come out of nowhere. And once again, it’s up to the operations team to figure out what happened and how to fix it.

In this post we’ll look at how request limits work in 2025, how Microsoft enforces them, and most importantly, how your team can stay compliant.

This is the fourth part of our Power Platform licensing series. In our previous articles, we covered

• Microsoft Power Platform licensing changes in 2025 and how they affect users,

• Power Platform Licensing Within M365 & D365 and what bundled access actually includes

• Standard vs. Premium Connectors in Power Platform and how to stay ahead of changes

Why request limits in Power Platform shouldn’t be taken lightly

In early versions of Power Platform, request limits were often overlooked. Enforcement was loose, and most apps never came close to hitting the thresholds.

That’s changed. Microsoft now treats request usage as a core part of license entitlement.  

Every license type includes a defined number of daily requests per user or flow, and enforcement is no longer optional. Whether you’re using Power Apps, Power Automate, or Dataverse, request volumes are tracked, monitored, and capped.

How Microsoft measures requests in 2025

Every interaction with the platform counts as a request. That includes:

• Saving or retrieving data from Dataverse, or any other data source

• Calling connectors (Standard or Premium)

• Each action step (which goes outside of your Power Automate) while running flows

• Triggering plug-ins or custom APIs

• Even system-level operations like lookups and validation

Microsoft provides a detailed breakdown of request capacity by license type. For example, users with a Power Apps Per User plan get a higher daily request limit than those using a Microsoft 365 license with Power Apps access. Background flows, unattended automation, and service accounts with Per Flow licenses have their own request pools.

What’s new in 2025 is how Microsoft surfaces this information

The Power Platform Admin Center now allows you to see request usage per user, environment, and app, but it takes a few steps to find the data. To check your request allocation, follow these steps:

1. Log in to the Power Platform Admin Center.

2. Navigate to the "Capacity" section in the left-hand navigation pane.

3. On the summary tab, look for the option to download reports (often found in an "Add-ons" or similar section).

4. Select "Download reports" and choose the type of report you want, such as "Microsoft Power Platform Requests."

5. Choose the scope for your report (e.g., Licensed User, Non-Licensed User, or Per Flow Licensed Flows).

6. Submit and download the report to view detailed usage data for each user or flow, including how many requests have been consumed.

You can also use Azure Monitor to set up alerts, but it does not natively track or alert on Power Platform request usage or allocation from the Power Platform Admin Center. Instead, it’s primarily built for observing Azure-native resources, such as virtual machines, databases, and Azure API Management, and can trigger alerts based on metrics or logs collected from those services.

What happens when you hit the limit

Request limits aren’t just theoretical. When usage exceeds your allocated capacity, Microsoft enforces throttling. Depending on the service and workload, this can mean:

• Flows that fail to trigger or complete

• Delays in data syncing or processing

• Errors when users try to save or update records

These disruptions can affect frontline business processes, like approvals, customer onboarding, or field updates, leaving teams confused about why things broke.

Most throttling surprises happen because teams aren’t actively tracking request consumption until it’s too late. To make matters worse, there's rarely a visible warning for end users. They just see errors. By the time IT gets involved, the platform may have already been throttled for hours.

How to manage requests proactively

The best way to manage request limits is to stop thinking of them as an afterthought. Request planning needs to be part of your architecture discussions from day one. Start by understanding your baseline. Use the Admin Center’s analytics to monitor which apps and flows are consuming the most requests.  

Look for patterns: Is usage spiking during certain times of day? Are a few apps responsible for the majority of consumption?

Once you have visibility, you can make smarter decisions, such as:

• Refactoring flows to reduce unnecessary steps or loops

• Offloading complex logic to Azure functions or other services where appropriate

• Consolidating data calls to reduce repetition

You don’t need to over-optimise from the start. But you do need to understand where your limits are and have a plan for what happens when you approach them.

How to plan for scale

As adoption grows, request volumes will too. But without a scaling strategy, your success can start to work against you, pushing you past request limits.

Microsoft offers a few options for scaling request capacity:

• Per App and Per User licenses each include defined request limits

• Pay-As-You-Go plans allow flexible scaling, with request overages billed through Azure

• Add-on request packs allow organisations purchase extra capacity without changing license types  

The right option depends on your usage profile. High-volume solutions used by a small group may benefit from Pay-As-You-Go. Department-wide apps might justify more robust licensing.  

(Note: Currently all organisations are in transition period with higher request limits. The transition period ends after Power Platform Admin Center reports are generally available. Organisations then have six months to analyse their usage and purchase licenses that are appropriate before strict enforcement on license limits begins. More info here.)

Don’t let service accounts become bottlenecks

A common pain point for many teams is the use of service accounts or shared automation users. These accounts often own high-volume flows or integrations, but they come with a fixed request limit, just like any other user.

When you hit those limits, automation fails, even if every individual user is well within their allowance.

The solution is to assign Per-Flow licenses to critical service flows. This plan reserves dedicated capacity for each licensed flow, regardless of who owns or triggers it, and does not consume from the tenant’s non-licensed user request limits.

It’s also a best practice for long-term maintainability, as it decouples business logic from individual users and ensures key automations remain stable over time.

Make request management part of governance

If you’re running a Center of Excellence or managing a large Power Platform deployment, request limits need to be part of your governance model.

That means:

• Including request tracking in solution review checklists

• Training makers to understand how their design choices affect request usage

• Defining escalation paths for throttling issues

• Monitoring usage trends and forecasting future needs

Build smart, scale smoothly

Request limits aren’t just technical constraints. They’re signals that your platform usage is growing and needs more intentional design. By understanding how requests work, monitoring them proactively, and scaling smartly, you can keep apps running smoothly and avoid the surprise of throttling.

Not sure what the right licensing setup is for you? Contact us to discuss your use case.

Up next in this series:

• Smarter spending with Power Platform — Managing costs for future scaling

‍