Power Automate: request limits and error 429

A flow slows during an import and the connector returns error 429. The administrator sees 40,000 requests in one table, 200,000 in another, and only eight thousand in operational statistics. Another licence may be the right answer to insufficient daily capacity. It will not automatically fix a short burst against a particular API.

Distinguish Power Platform request entitlements, transitional limit enforcement and technical service protection. The word “limit” does not describe the same meter, time window or remedy in each case. A successful run above an official entitlement does not establish that the design fits licensed capacity permanently.

Content reviewed on 21 October 2026. This article focuses on Power Automate cloud flows and calls to Dataverse or connectors. Agent flows use different metering; desktop flow executions themselves do not consume Power Platform requests under current documentation. Examples below are our calculations, rather than measured tenant performance.

One flow run is not one request

The requests and allocations overview includes connector API calls, HTTP actions and built-in Power Automate actions such as Initialise variable or Compose. Successful and failed actions, retries and extra pagination requests count. Twenty loop items can execute the same step twenty times. Include the trigger and control actions too: the FAQ counts one trigger and one executed action as two actions, rather than one.

Do not start budgeting with run counts. Establish actual counted action executions along one path, loop iterations, active branches and retries. A skipped branch action is different from an action executed a thousand times inside a loop. Compare the design with run history, rather than only the number of blocks on the canvas.

Microsoft also states that a Power Automate call to Dataverse is not automatically counted twice in this assessment merely because it crosses two services. This does not make every complex integration a single operation; account for additional steps actually triggered and relevant operations under their own rules.

Three layers of limits

The cloud flow limits also describe performance profiles and operational values. Do not directly translate these into a particular user's contractual entitlement. Establish whether the table concerns allocations, transitional enforcement or target-connector limits first.

Power Automate documentation also identifies an independent 100,000-request limit per five minutes, regardless of user licence. Do not confuse this with Dataverse's much lower default API request count over the same interval. They are different layers of the same flow.

Why Premium shows both 40,000 and 200,000

Current allocation documentation explicitly describes a transition period for all organisations. During it, Premium and seeded user limits are applied per cloud flow; the target model uses user entitlements. Process and legacy per-flow plans remain flow capacity after transition too. Design against the official entitlement, rather than only a more generous currently observed ceiling.

The table does not give a Premium user 40,000 plus 200,000 combined. These figures describe different levels and stages of enforcement. Microsoft says official enforcement will not begin until at least six months after usage reporting becomes generally available. Without a confirmed milestone and resulting date, do not invent a transition-end date for the project.

Included Power Platform capabilities in certain Microsoft 365 plans have an official 6,000-request allocation per 24 hours, rather than automatic Premium entitlement. The Microsoft 365 E5 name alone does not place a flow in an arbitrarily high Power Automate profile. Connector usage rights and capacity are related but separate checks.

Determine whose consumption it is

The Power Automate licensing FAQ distinguishes automated and scheduled flows from manual flows. Automated and scheduled flows typically use the owner's limits; manual flows can use the invoking user's limits. The account stored in a connection is not necessarily the identity determining the flow's full entitlement.

Do not count one person's entitlement again for every environment. Two environments do not create two allocations from the same licence. Nor can unused requests from another employee simply be transferred into a common user pool. Distinguish multiple applicable licences held by one person from different people's capacity.

Non-licensed identities, such as application users, have a separate tenant pool. Creating another service principal does not create another independent tenant pool. Documentation also identifies cases where a service-principal-owned flow uses Process, an applicable flow group or a designated licensed user's limits instead. Changing ownership type therefore requires recalculation, rather than merely removing a service account password.

A calculation exposes problems before an incident

Hypothetical model: one Premium user owns scheduled imports in two environments. The actions count towards requests, and these are not Process flows or another special capacity model. One import processes 1,200 records with four counted actions per record, plus 200 other counted actions outside those repeated four steps, including the trigger and loop control.

The official 40,000 entitlement is exceeded by 5,500, although each individual import uses only 5,000 and current transitional limits might permit execution. A report limited to the first environment would show 31,500 and hide the problem. Retries and pagination are added only because the model's original four actions and fixed component exclude them. Do not add them again to real consumption totals that already include them.

For cloud flows, documentation describes a rolling 24-hour window. A batch just before midnight followed by another just after midnight does not automatically create two independent daily capacities. Daily exports help show trends but do not establish consumption over every possible rolling window.

Error 429 can occur far below daily entitlement

Dataverse service protection tracks request counts, combined execution time and concurrency. Documentation gives defaults per web server: 6,000 requests within five minutes, 1,200 seconds of combined execution within the same window, and concurrency of 52 or higher depending on the environment. Limits can vary; these are not universally guaranteed performance figures for every tenant.

Execution time is aggregated. Several expensive concurrent requests can therefore consume 1,200 seconds of work within five minutes of elapsed time. More parallelism does not create free processing capacity; it may move the constraint from request count to execution time or concurrency.

For example, the same caller sends 7,000 Dataverse requests within four minutes to one web server using that default limit. Daily consumption may remain below 40,000, but the five-minute request count is not satisfied. Time or concurrency can constrain the flow earlier. This explains the mechanism under stated assumptions; it does not promise identical errors at the same request number in every tenant.

With Dataverse, respect Retry-After and schedule retries accordingly. Do not respond to overload with an immediate unbounded retry loop. Check other connectors' documentation and returned errors individually; not every API uses the same rules. Reduce excessive batches, spread processing and ensure a safely repeated operation does not create duplicate business records.

Reports do not cover the whole Power Platform

The current allocations and reporting guide directs administrators through Licensing, Capacity add-ons and Download reports to Microsoft Power Platform requests reports. It distinguishes Licensed User, Non-licensed User and Per Flow Licensed Flows. Portal navigation can change; the selected report type matters too.

Documentation labels these downloadable reports as preview and limits their coverage to Power Automate API requests. In this form they do not include all Power Apps, Dataverse and Copilot Studio API requests. Missing consumption does not necessarily mean the service had no activity.

Two further reading errors are documented for the Licensed User report. Entitlement can appear per user, day and environment, but must not be multiplied by environment count. Power Apps per app and corresponding PAYG entitlements can incorrectly show zero rather than the relevant 6,000. A zero in that field does not automatically prove a missing licence.

When to add capacity and when to change operation

If the actual issue is total entitlement, assess appropriate higher user coverage or Process capacity for the particular flow. Current documentation gives Process 250,000 PPR and permits direct stacking on one solution-aware flow. Flow groups have different sharing and stacking rules; see Premium, Process and service accounts.

The requests add-on, described as adding 50,000, is not currently a simple assignment button for one throttled flow. The overview explicitly says it cannot currently be assigned to users or flows. Do not order it based on its name without checking how the required capacity will actually be allocated.

If the cause is connector throttling or service protection, start with rate, concurrency, operation types and controlled retries. Higher daily entitlement does not remove the target API's rules. Also distinguish Dataverse request capacity from database, file and log storage; our Dataverse capacity article explains those measurements.

Procedure for a slowdown or error

1. Save the time, flow and run ID, specific action, connector response and any Retry-After value.
2. Determine whether the constraint is request entitlement, a Power Automate operational limit, a connector or Dataverse service protection.
3. Verify flow type, actual owner or invoking user and capacity model.
4. Total relevant consumption, including other flows and environments for the same user; do not multiply the same licence's entitlement.
5. Separate total consumption from short bursts and consider the rolling window.
6. Choose a targeted remedy: capacity, fewer unnecessary actions, spreading batches or controlled concurrency.
7. Verify the completed business outcome, rather than only a successful retry. Check duplicate and unprocessed items after remediation too.