Flows that chew through connector limits do not fail by chance. When a cloud flow is consistently throttled, the platform slows it, queues it, and if the pattern continues, turns it off after 14 days. Owners get emails. For Dataverse (and many Microsoft connectors), the run history shows 429s with Retry-After. Confirm for your connector. This is Power Automate throttling.

The fix is a discipline. Prove throttling with telemetry, find where action counts multiply, reduce trigger noise and parallelism, and right size capacity only if the math still says you are over. Do that and you will not enter the enforcement window.

Contents

Detect the 14-day enforcement: 429s, Analytics action spikes, and owner notifications

If a flow stays above throughput limits long enough, the system turns it off after 14 days. That outcome is documented and enforced per flow version on sliding windows. The proof is not a hunch or a single failed run. It is a sustained pattern.

Start with run outputs. For Dataverse (and many Microsoft connectors), throttling presents as HTTP 429 Too Many Requests and includes a Retry-After header. Confirm the behavior for your connector.

{
  "status": 429,
  "message": "Too Many Requests",
  "headers": {
    "Retry-After": "15"
  }
}

429 is the tell.

Now quantify the volume.

Open the flow and select Analytics > Actions to review counts and trends. Spikes in daily actions paired with elevated errors point to sustained pressure. The limits documentation updated in July 2026 calls out this Actions view explicitly.

In the Power Platform admin center, use Environments > Usage > Power Platform requests to see request volumes at environment scope. On 28 August 2026, this view was labeled preview in some tenants and availability varied. Both successful and failed actions count. Retries and pagination count too.

Owners receive emails when a flow is on track to be turned off. The sender for Alerts emails is PowerPlat-noreply@microsoft.com. Do not rely on email alone. People miss messages. Use the Monitor area to set alerts on success rates for high use flows so you catch issues sooner. On 28 August 2026, predefined alerts (including success rate for high use flows) were available and evaluated daily in the Monitor area.

An evidence checklist:

  • 429s present in run outputs with Retry-After values.
  • Analytics shows elevated daily action counts or a rising trend.
  • Request usage in the admin center confirms high volume across flows using the same connection.
  • Owner notifications about throttling or impending turn off.

Why throttling happens: chatty triggers and fan-out breach connector caps first

Most shutdowns trace back to patterns that multiply actions. The platform wide request limits matter, but in practice connector caps are hit first. Connector caps vary by connector and can change; confirm current limits on the connector reference page.

Two examples illustrate the bottleneck. The SharePoint connector documents 600 API calls per connection per 60 seconds. The Microsoft Dataverse connector documents 6,000 per connection per 300 seconds. You can breach those quickly with a chatty trigger or a wide fan out.

A chatty trigger fires on every change without meaningful filters. SharePoint list item change triggers without a filter on the fields that matter are a classic source. Dataverse table change triggers without OData Filter rows and selective columns do the same. Each small edit raises a run. Runs contain loops and calls, so the math escalates fast.

Fan out does the rest. Split on can debatch arrays into many concurrent runs. Apply to each with high concurrency will fire multiple connector calls at the same time. Parallel branches multiply pressure again. If those calls target the same connection, the per connection cap is the bottleneck.

It is design. When the input stream is noisy or high volume, you hit connector caps long before any tenant wide limit.

Look for these symptoms:

  • A trigger that raises runs for changes that do not matter to the business.
  • Arrays split into hundreds of tiny runs when a batched run would suffice.
  • Loops with concurrency near the maximum.
  • Multiple parallel branches that all call the same connector.

Tune concurrency and debatching to stop chewing through limits

Concurrency controls are not cosmetic. They decide how fast a flow spends connector budgets.

  • With Concurrency Control off, concurrent runs are unlimited. A busy trigger can stack many instances and hammer a connection.
  • With Concurrency Control on, you set the degree of parallelism between 1 and 100. The default is 25. Waiting runs are capped at 10 plus the degree of parallelism. For example, a degree of 10 yields a waiting cap of 20.
  • Turning on trigger concurrency reduces the Split on items limit to 100. Large arrays that used to debatch fully will stall or backlog.

These settings matter.

Two tuning moves have immediate effect:

  • Lower the trigger concurrency. For hot paths that call throttled connectors, set the trigger to 1 or a small value. This serializes runs and prevents a burst from breaking the per connection window.
  • Reduce loop concurrency. In Apply to each, set concurrency to the minimum that still meets your SLA. The default loop concurrency is 1 and the maximum is 50. Do not push it unless you have headroom.

Next, shape debatching. If Split on is enabled, pick a batch size that keeps the total requests per unit time under the connector cap. For large arrays, process in batches with a short delay to stay under the per connection cap so calls do not cluster into the same window.

Remember what counts. Successful actions, failed actions, retries, and pagination all count toward request limits. Retries, if configured for an action, still consume the same budget. That is why concurrency and retry policies must be considered together.

Refactor the flow: shape triggers, serialize hot paths, and respect Retry-After

Fixes that last reduce input noise and parallelism. They also back off politely when a downstream service says to wait.

Shape the trigger first. For Dataverse, set Filter rows to only the records and states you need, and enable Trigger conditions so that only qualifying changes start the flow. For SharePoint, apply filters in the trigger and select only the columns that matter. If you can move a filter into the trigger, do it. You remove runs entirely.

Serialize the hot path. Any path that calls the same connector repeatedly should run with low concurrency. Set the trigger concurrency to a small number and cap concurrency inside Apply to each loops that call the same connection. If a downstream API has a strict per connection limit, a flood of parallel calls competes for the same per connection cap and increases 429s.

Respect Retry-After. When a connector returns 429 with a Retry-After header, backing off avoids wasting retries. Honor the wait signaled by the header. You can add a defensive delay on the failure path to extend the wait further if needed. Wrap the risky action in a Scope with a run after on failure, then add a Delay that uses the seconds from the response or a conservative fixed value. If you also cap concurrency on the scope that holds the risky call, the combination reduces pressure at the connection, honors the downstream backoff signal, and limits fan out at the same time without relying on a single control to do all the work.

Also remove unnecessary parallel branches. It is tempting to split independent work to speed up a run. If the parallel work hits the same connector or the same connection, the flow spends the same budget in a shorter window and increases throttling risk.

Finally, consider simplifying debatching. If Split on is producing a storm of small runs, process larger batches in a single run and checkpoint progress. This keeps the number of connections and active runs down, which reduces contention.

When to buy capacity: Process, flow groups, Pay-as-you-go, and add-ons sized by math

Sometimes the design is clean and the workload still exceeds entitlements. That is when capacity uplifts make sense. Size them with math, not guesswork.

Licensing documentation published in August 2026 describes Process capacity and stacking behavior, and the request capacity add-on sizes. Confirm current specifics before purchasing.

Start with a simple estimate: actions per run multiplied by runs per day. If that total exceeds what user licenses allow, add dedicated capacity. Process assignment requires a solution-aware flow. On 28 August 2026, a Power Automate Process license included up to 250,000 actions per day. Up to 10 Process licenses could be stacked on a single cloud flow. On the same date, assigning a Process license to a flow group shared 250,000 actions per day across up to 25 flows. Stacking applies only to a single flow, not to a group.

Request capacity add-ons also exist. On 28 August 2026, each add-on added 50,000 requests per 24 hours. Add-on assignment can be subject to licensing transition timing constraints. Check the current licensing guidance.

If throttling is widespread in an environment, Pay-as-you-go is an option. Link the environment to an Azure subscription and usage above included amounts is billed to Azure meters. This prevents throttling across flows in that environment when user entitlements are the constraint.

A quick comparison:

Option Scope Daily allocation Stacking or sharing Billing or priority Notes
Process license Single flow 250,000 actions Stack up to 10 per flow Highest license priority on the flow Flow must be solution-aware
Flow group (Process) Up to 25 flows 250,000 actions shared No stacking for groups Highest license priority on assigned flows Good for related flows with shared peaks
Request capacity add-on Tenant or environment allocation +50,000 requests Stack add-ons to raise pool Adds 50,000 requests per 24 hours Timing constraints can apply
Pay-as-you-go Environment Above entitlements billed Scales with use Billed to Azure subscription Avoids throttling when entitlements are the limit

How to decide:

  • If one flow is the outlier, assign Process directly and stack if required.
  • If many related flows need a shared pool, use a flow group.
  • If an entire environment regularly exceeds included limits, enable Pay-as-you-go.
  • If usage is spiky around events, combine Process on hot flows with a small number of request add-ons to cover peaks.

What to watch carefully

A few gotchas can undermine good fixes if you do not plan for them.

  • Trigger concurrency reversals. For some connectors, once you enable trigger level concurrency you cannot disable it in the designer. SharePoint triggers will throw CannotDisableTriggerConcurrency if you try. The documented workaround involves exporting and editing the flow JSON. Plan the change in a safe window.
  • Split on reduction. When trigger concurrency is enabled, the Split on items limit drops to 100. Large arrays that used to debatch fully will now backlog or partially process. If you depend on Split on for throughput, measure the new ceiling first.
  • Waiting runs cap. With Concurrency Control on, waiting runs are limited to 10 plus the degree of parallelism. Extra trigger events may be retried by the connector and still fail if the queue stays full. Silent gaps can appear unless you monitor for missed events.
  • Owner performance profile. If the original owner leaves or loses a Premium license, a flow can switch to a Low performance profile. Limits tighten and throttling risk rises. Maintain ownership hygiene and consider Process licensing for critical flows.
  • Auto off rules beyond throttling. Flows with continuous errors are turned off after 14 days. Flows without trigger activity can be turned off after 90 days, with notifications and exceptions for premium or capacity licensed flows. Do not mistake these for throttling.
  • Monitoring granularity. The Monitor area of the Power Platform admin center provides metrics and alerts. On 28 August 2026, metrics and alert evaluations were daily aggregates and required tenant-level analytics, and recommendations required managed environments.

Warning: Reconfiguring trigger concurrency or debatching on a production flow changes behavior immediately. Test in a copy with the same connectors and connections before flipping settings.

This post does not cover custom connectors or non Microsoft connectors.

My take

Treat throttling as capacity planning plus design hygiene. Prove the condition quickly with 429s and action counts. Then attack noise first. Shape the trigger so you start fewer runs. Reduce fan out. Serialize hot paths by capping the trigger and loop concurrency. Only when the math still says you exceed entitlements should you add Process, flow group capacity, Pay-as-you-go, or request add-ons.

Monitoring is the safety net.

The recommendation is simple. Put a hard cap on concurrency, eliminate unnecessary debatching and parallel branches, and introduce polite backoff that honors Retry-After. Set up alerts for high use and success rate, and build a lightweight usage view from run history and the Analytics Actions chart. That small weekly check helps you avoid buying capacity you do not need.

If a program manager asks whether to buy capacity first, the counterfactual is clear. Buying capacity into a chatty design masks the real fault, raises cost, and still risks hitting connector caps like the SharePoint per connection limit. Fix the design, then size capacity with actions per run multiplied by runs per day. Do that and the shutdown never triggers.

Sources

Categorizado en:

Power Automate,

Etiquetado en:

, , , , ,