Power Automate Limitations: Request Limits, Licensing and Workarounds
Power Automate limitations as of September 2026: request limits by license, throttling, turn-off rules, loop and timeout caps, and when to move to Logic Apps.
Luka Abramovic21 min read
Of all the Power Automate limitations, the one that catches teams out is that the daily request limit belongs to a person, not to a flow. As of September 2026, the official allowance for a Power Automate Premium user is 40,000 Power Platform requests per 24 hours, shared by every flow that runs on that user's license. Every trigger and action counts, including a Compose step, a failed action, each retry and each extra page of results. Microsoft isn't enforcing that figure yet. Flows are throttled at looser transition-period limits, 200,000 requests per flow for a Premium owner, until at least six months after its usage reports become generally available, a date Microsoft hasn't set (Microsoft Learn). Flows that run smoothly today can already be far over the limit Microsoft tells you to design for.
This guide covers cloud flows: for each limit, the number, what happens at it and what to change, checked against Microsoft Learn in September 2026. The 14-day turn-off after a premium flow's owner leaves, and how retries create duplicate records, are in our guide to connecting business systems. Desktop flows are in our RPA guide.
1. The API request limit is a budget per person, not per flow
For a cloud flow, one Power Platform request is one execution of a trigger or action. These are the official limits, and the looser ones enforced during the current transition period (request limits and allocations, licensing FAQ):
| License the flow runs under | Official limit | Enforced during the transition period |
|---|---|---|
| Microsoft 365 (Office 365), Power Automate Free, Dynamics 365 Team Member, any trial | 6,000 per user, across all their flows | 10,000 per flow |
| Power Automate Premium, Power Apps Premium, Dynamics 365 Enterprise or Professional | 40,000 per user, across all their flows | 200,000 per flow |
| Power Automate Process or Hosted Process, assigned to the flow | 250,000 per license, and up to 10 licenses can be stacked on one flow | 500,000 per license |
| Flow owned by a service principal, standard connectors only | 25,000 per tenant, shared by all such flows (more in Dynamics 365 app context) | No separate figure published |
Four rules decide whose budget a run spends:
- Automated and scheduled flows spend the owner's budget. Instant flows spend the budget of whoever starts them. A Process license on the flow replaces both.
- Limits don't combine. An owner with Premium and a Dynamics 365 license gets 40,000 for flows in each context, not 80,000.
- The window slides. Each run is checked against the previous 24 hours, with no midnight reset.
- Two more caps apply: 100,000 requests per flow in any five minutes, whatever the license, and, during the transition period, 1,000,000 actions per user per day across all their flows.
Count a flow's actions before Microsoft does
Skipped actions are free, but Initialize variable and Scope count like any connector action. A loop counts once, plus every action inside it once per item, so a loop of two actions over ten items costs 21 (what counts as an action). As a formula, with Microsoft's sizing rule for Process licenses on the last line:
Actions per run = 1 (trigger)
+ actions outside loops that ran
+ for each loop: 1 + (items × actions inside that ran)
+ retries + extra pages
Actions per day = actions per run × runs per day
Process licenses = actions per day ÷ 250,000, rounded up (10 at most per flow)
In Excel, with actions per run in B2 and runs per day in B3:
=ROUNDUP(B2*B3/250000, 0)Worked example: one missing filter, 33 times the actions
An illustrative example. A scheduled flow runs every 15 minutes, 96 times a day. It reads open orders from a SharePoint list and runs five actions outside its loop. Inside the loop, a Condition checks each order. The ten or so orders that changed since the last run go on to three more actions, and the rest skip them, which costs nothing. Extra pages are left out, so the first row is an underestimate.
| Design | Actions per run | Actions per day | Against the limits |
|---|---|---|---|
| Reads all 1,500 open orders and checks each one | 1 + 5 + 1 + (1,490 × 1) + (10 × 4) = 1,537 | 147,552 | Under today's 200,000 per flow, so it runs without complaint, but 3.7 times the official 40,000 for a Premium owner. |
| Reads only orders modified since the last run | 1 + 5 + 1 + (10 × 4) = 47 | 4,512 | Fits inside a Microsoft 365 license's 6,000. |
The fix is the connector's Filter Query and Top Count settings, so the flow fetches only what changed. On event-triggered flows, a trigger condition (the trigger's Settings, Trigger conditions) stops runs that would do nothing from starting. To reshape or filter a list, use Select or Filter array: each is one action, however many items it processes.
Read your real numbers
For one flow, open its details page, then Analytics and the Actions tab. For every user and Process-licensed flow, an admin can download the usage report from the Power Platform admin center: Licensing, Capacity add-ons, the Summary tab, Download reports, New, Microsoft Power Platform requests, the scope you need, and Submit. The preview report repeats a user's entitlement in every environment, but the limit applies once per user per day, so compare each user's total across environments with one official entitlement. It counts Power Automate requests only; Dataverse's own limits are in our business software API limits reference.
2. What happens at a limit: slowed, then switched off
Going over a request limit delays runs rather than failing them, and the flow shows a banner. Microsoft's licensing FAQ gives the scale: 500 actions over the limit has no visible effect, while 50,000 over can slow a flow for several days. Separately, these rules turn flows off (limits page, license enforcement):
| Rule | When it applies | What to know |
|---|---|---|
| Consistently throttled | Above the transition limits for 14 consecutive days | Editing and saving the flow resets the counter, which buys time to get a Process license. |
| Always failing | The trigger or actions fail continuously for 14 days | For example, a connection that broke after its creator's password or MFA reset: runs fail until someone signs in again. |
| No trigger activity | Not triggered for 90 days | Only when the owner has no premium or Process license, with 30 days' notice. Annual and other rarely triggered flows are the ones at risk. |
| Premium flow without a license | The owner left or lost their Premium license | Downgraded, then turned off after 14 days. |
| License enforcement | Admins are notified that flows need licenses | After 90 days, creating, copying and restoring environments is disabled. After 180 days in total, flows can be suspended. |
| Data policy change | The flow uses connectors a new policy separates or blocks | Suspended once the policy reaches the environment (section 7). |
Turning a flow back on has its own trap. A polling trigger picks up where it left off, but a webhook trigger processes only events that arrive after the flow is on again (Microsoft's trigger guidance). After a suspension, give each webhook-triggered flow a catch-up run that finds the records changed during the gap.
Connector limits often come first
Connectors also limit calls per connection, and Microsoft's limits page notes these are often reached first. The SharePoint connector allows 600 operations a minute per connection, shared by every flow that uses it, and a custom connector allows 500 requests a minute. Past the limit, actions fail with a 429 error such as "Rate limit is exceeded. Try again in 27 seconds." (licensing FAQ, limits page). Two heavy flows on one SharePoint connection share one budget, so schedule them apart.
Options when a redesigned flow is still over
- Assign a Process license, which gives the flow its own 250,000 a day, and stack more if one isn't enough (section 3).
- Link the environment to an Azure subscription for pay-as-you-go. Its flows can then exceed their daily entitlement without being throttled, and the overage meter, $0.00004 per request, is still "coming soon" and unbilled until generally available (pay-as-you-go meters). But linking switches on every meter there: $0.60 for each premium cloud flow run not covered by a Power Automate per-user or per-flow license, and $48 per GB a month for Dataverse database storage above 1 GB. Check who runs what first.
- Buy capacity add-ons and open a support ticket. Add-ons can't be assigned during the transition period, but a ticket with the flow's details and the purchase gets 30 days' relief from throttling. Flows that already have a Process license don't qualify.
3. Premium connectors and the Process license
Microsoft 365 licenses include standard connectors only. A flow needs a premium entitlement once it uses a premium connector, such as HTTP, SQL Server, Dataverse or any custom connector, or the on-premises data gateway, business process flows or desktop automation (licensing FAQ). Without one, runs fail with DirectApiAuthorizationRequired (error reference).
US list prices as of September 2026, paid yearly, are $15 per user a month for Premium and $150 a month for a Process license, which is assigned to one flow in one environment (Microsoft's pricing page). A pay-as-you-go environment charges $0.60 per premium run instead.
| Situation | Arithmetic | Cheapest option |
|---|---|---|
| Instant (button) flow started by N people | N × $15 against $150, level at 10 people | Premium for fewer than 10 people, Process for more |
| Flow run rarely, in a pay-as-you-go environment, by people without Premium | $0.60 × runs a month, level with one Premium seat at 25 runs and one Process license at 250 | Pay-as-you-go below 25 runs a month |
| Flow that needs more than its owner's 40,000 a day, or must keep running whoever owns it | $150 a month for 250,000 a day, and $150 per extra 250,000 up to 10 licenses | Process, stacked if needed |
Assigning a Process license, and the traps
- Put the flow in a solution. Only solution flows can take Process capacity: Solutions, select a solution, then Add existing, Automation, Cloud flow. The PowerShell cmdlet
Add-AdminFlowsToSolutionmoves every non-solution flow in an environment at once. - Change the plan. On the flow's details page, select Edit, choose Process plan and save (Process capacity).
- Save the flow again. Otherwise the plan may wait for Microsoft's weekly background refresh, and the portal's "needs a license" banner can take up to seven days to clear.
- Budget per environment. Development, test and production copies are separate flows, and each needs its own Process capacity. Premium user licenses work in every environment.
- License child flows explicitly. The licensing FAQ says a Process license on a parent flow doesn't cover its child flows, while the request limits page still says it does. Assign capacity to each child that uses premium connectors, or get Microsoft's answer in writing.
- Check that flow groups exist before planning around them. The FAQ, updated in August 2026, lets up to 25 solution flows share one Process license as a flow group, without stacking. The Process capacity page, last updated in March 2026, still calls flow groups planned.
Before buying, an admin can start a free 30-day trial of Process licenses from the Microsoft 365 admin center. Trial licenses stack, so you can prove a flow's volume first.
Power Apps Premium and Dynamics 365 licenses cover premium flows only in an app's context. Flows started from a canvas app qualify automatically, as do Dynamics 365 users' flows that use Dataverse on Dynamics 365 tables. Other flows must be associated with the app or become enforcement targets (license enforcement).
4. The owner's license sets the flow's limits
Ownership decides an automated or scheduled flow's limits as well as its cost. When the original owner leaves the organization, the flow reverts to the Low performance profile (limits page). Apply to each loops and pagination then stop at 5,000 items instead of 100,000, the daily limit falls to the Microsoft 365 level, and failed calls get up to 2 retries instead of 12. A flow that loops over 20,000 rows works until its owner's account goes.
Change the owner the right way
- A solution flow can change owner in place. Select Edit in the flow's Details section, remove the current owner and enter the new one. Both become co-owners. The new owner's license and limits can take up to seven days to apply unless someone edits and saves the flow. If the new owner has no premium license, a premium flow keeps running for 30 days, then is turned off (change a flow's owner).
- A non-solution flow can't change owner, because the owner is part of the flow's identity. Add it to a solution first. Export and import instead creates a new flow with an empty run history.
- A service principal can own a flow, so the flow doesn't depend on anyone's employment. It draws on the tenant's pool for non-licensed users (section 1), and a premium flow it owns needs a Process license or a designated licensed user. Its connections still matter: a person's connection breaks when they change their password or leave, which is why Microsoft recommends service principal connections for production flows (error reference).
Our default for any flow a business process depends on is a solution flow, owned by a service principal, with a Process license, service principal connections wherever the connector supports them, and two named people as co-owners.
To see your exposure across the tenant, an admin can run this. The loop over environments follows Microsoft's own example, written for tenants with fewer than 500 environments.
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser
Add-PowerAppsAccount
# 1. Every flow in the tenant
Get-AdminFlow | Export-Csv -Path .\all-flows.csv -NoTypeInformation
# 2. Flows Microsoft already flags as at risk of suspension for licensing
$environments = Get-AdminPowerAppEnvironment
$atRisk = foreach ($env in $environments) {
Get-AdminFlowAtRiskOfSuspension -EnvironmentName $env.EnvironmentName
}
$atRisk | Export-Csv -Path .\flows-at-risk.csv -NoTypeInformation
# 3. Flows that call HTTP directly: premium, and governed by data policies
foreach ($env in $environments) {
Get-AdminFlowWithHttpAction -EnvironmentName $env.EnvironmentName
}After you fix a flow's license, edit and save it. PowerShell can take up to 24 hours to stop listing it (licensing FAQ, PowerShell for admins).
5. Loop, paging and concurrency caps that fail quietly
| Setting | Limit | How it goes wrong |
|---|---|---|
| Apply to each | 5,000 items on the Low profile, 100,000 otherwise. Sequential by default, with concurrency from 1 to 50 | Past the cap, the run fails with WorkflowRunActionRepetitionQuotaExceeded. With concurrency on, a nested loop still runs one item at a time. |
| Pagination threshold | 5,000 items on Low, 100,000 otherwise | Dataverse List rows with pagination on stops at the threshold without a next-page link, so a larger table is cut short with no error. |
| Default page sizes | Excel's List rows present in a table returns 256 rows, and Dataverse's List rows 5,000 | Without pagination, the flow processes the first page and reports success. |
| SharePoint Get items | List view threshold of 5,000 items | Fails with "exceeds the list view threshold". Filter on an indexed column, or use $top=5000 with pagination. |
| Do until | 60 iterations and one hour by default, up to 5,000 iterations | Reaching a limit ends the loop, which can still be marked Succeeded. See the guard below. |
| Trigger concurrency control | Off by default (unlimited parallel runs). When on, 1 to 100 at once (default 25), with that number plus 10 waiting | Can't be undone without deleting and re-adding the trigger. Triggers arriving while the queue is full are retried by the connector and may never run. Split On falls to 100 items. |
Sources: Microsoft's limits page, error reference, Dataverse List rows, Excel Online (Business) connector, troubleshooting guide and parallel execution guidance.
Guard every Do until loop
Cloud flows run on the same engine as Azure Logic Apps (a flow's runtime endpoint is a logic.azure.com address). Microsoft's Logic Apps documentation says an Until loop that reaches its count or timeout limit exits, and if the actions in its last iteration succeeded, the loop is marked Succeeded (Logic Apps loops). The flow then carries on as if the job had finished. Logic Apps can fail the loop instead, with "operationOptions": "FailWhenLimitsReached" in its JSON. In Power Automate, repeat the exit test after the loop:
Do until: @equals(variables('JobStatus'), 'Completed')
Change limits: Count 60, Timeout PT1H (the defaults), or your own
Condition, placed after the loop, with the same test:
@equals(variables('JobStatus'), 'Completed')
If yes: carry on
If no: the loop ran out of iterations or time, not work.
Send the alert, then Terminate with Status: FailedThe same page warns that Increment, Decrement and Append to variable can give unpredictable results in parallel iterations, so keep any Apply to each that updates a variable sequential, or collect its results with Select.
6. Timeouts, run duration and payload size
| Limit | Value | Design consequence |
|---|---|---|
| Outbound synchronous HTTP request | 120 seconds | Anything slower needs the asynchronous pattern below. |
| Outbound asynchronous request | Up to 30 days | The service answers 202 and gives a status URL to poll. |
| Inbound request (HTTP trigger, instant flows) | 120 seconds | Put the Response action first. Actions after it keep running past the limit. |
| Run duration | 30 days, including waiting approvals | Pending steps time out on day 30, so approvals without an expiry and Delay until dates beyond 30 days fail. Microsoft's answer is a relay: end the run and start a new one, with the state kept in Dataverse or a file. |
| Run history retention | 30 days from the run's start | Anything an auditor may ask for later has to be logged elsewhere. |
| Message size | 100 MB, or 1 GB where the action supports chunking | The whole payload counts, not just the file. The Excel Online (Business) connector supports workbooks up to 25 MB. |
| Content throughput per 24 hours | Official: 200 MB on Low, 2 GB on Medium (Premium owners), 10 GB on High (Process). Transition: 2.5 GB, 20 GB and 50 GB | Counts data written to and read from run history. Copying 400 five-megabyte PDFs a day (illustrative) moves at least 2 GB, already a Premium owner's official ceiling. |
| Flow definition | 500 actions, nesting depth of 8, 250 variables, 25 Switch cases | Split large flows into child flows, after reading the data policy catch in section 7. |
| Recurrence | At most once every 60 seconds | Anything more frequent needs an event trigger, or Logic Apps, whose recurrence goes down to one second. |
Sources: the limits page, error reference and Excel Online (Business) connector.
Calls that take longer than two minutes
If the flow calls your own API or an Azure Function, make it answer at once with 202 Accepted and a Location header pointing at a status URL. The HTTP action follows this asynchronous pattern by default, polling that location until the response isn't 202 (workflow actions reference). A timeout followed by a retry is also where duplicate records come from; the fixes are in our integration guide.
Excel as the data store: the duplicate-row trap
Microsoft's Excel Online (Business) connector page lists a known issue: complicated formulas or too many rows can make recalculation slow enough to time the connector out, and the retry policy can then insert the same data more than once. Microsoft suggests simpler formulas. Our default: set that action's retry policy to None, check for the row before adding it, and where you can, keep the data in a SharePoint list or Dataverse table, with Excel for reporting.
7. Data policies that block connectors
Admins control which connectors can be combined through data policies, also called data loss prevention (DLP) policies, which sort connectors into Business, Non-Business and Blocked. A flow can't mix Business and Non-Business connectors or use Blocked ones, and a new policy puts every connector in Non-Business until an admin moves it (connector classification).
- A policy change reaches existing flows. Flows that now break the policy are suspended, connections to fully blocked connectors are disabled, and running flows fail when they next use one. Enforcement usually lands within an hour and can take 24 hours (data policies).
- Some connectors can't be blocked, including SharePoint, Excel Online (Business), OneDrive for Business, Microsoft Teams, Microsoft 365 Outlook, Planner, Approvals, Notifications and Dataverse, the only premium one, though admins can put them in either group. Newer advanced connector policies can restrict them with an allowlist, but don't yet cover HTTP or custom connectors.
- Child flows depend on the HTTP connector. Microsoft warns that the group an admin picks for HTTP can stop child flows running, and suggests a dedicated environment where HTTP is allowed and only named makers can build.
Before anyone builds, ask your Power Platform admin four questions. Which environment will the flow live in, and which policies apply there? Which group is each connector in the design in? Is HTTP allowed there, and to which endpoints? Does the environment have Dataverse? Without it, flows can't go into solutions, so they can't change owner or take a Process license.
8. When to move a flow to Azure Logic Apps or code
Azure Logic Apps runs the same kind of workflow definition, bills per execution or per hosting plan rather than per user, and has different limits (Logic Apps limits, Microsoft's migration guidance). These are the signals we use.
| Signal | Where to move it | Why |
|---|---|---|
| A run must wait longer than 30 days, for a renewal or a slow approval | Logic Apps, or keep the state in a table and check it daily | A Consumption logic app can run for up to 365 days (90 by default). One setting controls both run duration and history retention. |
| Volume beyond 10 stacked Process licenses (2.5 million actions a day), or bursts above 100,000 in five minutes | Logic Apps Standard | Standard has no fixed limit on executions per five minutes; its compute sets the ceiling. Consumption allows 100,000, or 300,000 in high-throughput mode (preview). |
| Changes need version history, review and automated deployment | Logic Apps Standard, or code | Standard projects work with Git and deploy through pipelines using ARM or Bicep templates. |
| The flow must reach a private network without a gateway | Logic Apps Standard | Virtual network integration and private endpoints. |
| The logic needs automated tests, idempotency keys or a screen where staff fix failed records | Code | These are hard to express as flow branches. |
Three traps when a flow moves to Logic Apps
- Loops change behavior. A Logic Apps For each runs 20 iterations in parallel by default, where Power Automate's Apply to each runs one at a time, so the variable warning in section 5 applies to every migrated loop (Logic Apps loops).
- Connections don't come across. Microsoft's migration guidance says to recreate them by hand, then test them, especially SQL Server and Key Vault connections.
- The bill counts what the daily limit counted, and more. Consumption meters every execution beyond a small free allowance of built-in actions: an action retried five times is six executions, a loop of one action over 10 items is 11, and a polling trigger is billed for every check, even when it finds nothing. Managed connector calls cost Standard or Enterprise connector rates on both plans, while Standard runs built-in operations free (Logic Apps billing).
Price it before you move it. An illustrative example: a flow using one Process license's full 250,000 actions a day runs about 7.5 million executions a month. At Consumption list prices of $0.000025 per built-in action and $0.000125 per Standard connector call (Azure pricing, US prices as of September 2026), that is about $188 a month if every step is a built-in action and about $938 if every step calls a connector, against $150 for the Process license. Our rule of thumb: move a flow for the 30-day limit, deployment discipline or private networking, not to cut the bill.
A one-hour limits review for your busiest flow
Run this with the flow's owner and your Power Platform admin.
| Check | Where to look | Warning sign |
|---|---|---|
| Whose license the flow runs on | The flow's details page, Plan section, and Solutions | A person who could leave, a trial, a Microsoft 365 license on a premium flow, or no solution (so no owner change or Process license) |
| Actions per day | Analytics, Actions tab, and the admin center's requests report | Above the official limit for that license, even if nothing is throttled yet |
| Reads and loops | Every Get items, List rows, Apply to each and Do until | No filter, pagination off, a Do until without a guard, or a variable updated in a parallel loop |
| Trigger settings | The trigger's Settings | Concurrency control on without a reason, or no trigger condition on a busy event trigger |
| Waits and slow calls | Approvals, Delay until, webhook and HTTP actions | No expiry, a wait that can pass 30 days, or a call that can take longer than 120 seconds |
| Excel writes | Add a row into a table actions | A workbook with heavy formulas and the default retry policy |
| Connections | The flow's connection references | Connections created by a person, on a flow that has to outlive their job |
| Data policies | Your admin's answers to the four questions in section 7 | HTTP or a key connector in a different group from the rest of the flow |
| Suspension risk | The PowerShell script in section 4 | Listed as at risk, or a rarely triggered flow whose owner has no premium license |
If a flow your business depends on is being throttled, keeps getting switched off or has to outlive the person who built it, bring this review filled in, with the flow's Analytics numbers. We'd start with whose limits it runs on, then price it three ways: as a Process-licensed flow, as a logic app and as code. Our internal systems and integration work begins there.