Performance Tuning for Power Automate Flows

A Power Automate flow that takes minutes for a task that could really be done in seconds doesn't just cost time. It burns through unnecessarily many of your plan's limited action requests, drives up timeout errors in downstream systems, and makes troubleshooting harder because every run has to work through more steps. The good news: most performance problems in Power Automate come down to three levers, which Microsoft documents in detail in its own coding guidelines. As of: July 2026.

This article summarizes how targeted parallelism, cutting unnecessary actions, and the right connector and data choices help you build noticeably faster flows, based on the official Microsoft documentation for Power Automate. That way you stay in control of which lever has the biggest effect on your specific flow, instead of randomly turning dials that barely change anything.

Why flows become slow in the first place

Before you optimize, it's worth looking at the root cause. According to the guidance on Discovering performance issues many slowed-down flows simply hit their daily Power Automate limits. The action analytics in "My flows" show you how many action requests a flow actually consumes, and Power Automate even emails owners when a flow repeatedly runs into action limits. Just as important: the connected services themselves also enforce protection limits, which show up in your flow as error 429 (too many requests) or 5xx (timeout). These limits differ by connector and service, which is why the exact same flow logic can perform very differently on SharePoint than on Dataverse or an external API.

Lever 1: Use parallelism deliberately

Parallel branches for independent steps

According to the guidance on parallel execution and parallelism parallel branches pay off whenever two or more actions don't depend on each other and each individually takes longer than five seconds. According to Microsoft, typical use cases are non-blocking approval requests, quorum-based approval processes, simultaneously creating or updating records across multiple systems, and initializing multiple variables in parallel.

Concurrency control in Apply to each loops

The effect becomes even clearer in loops. By default, an Apply to each loop works sequentially, item by item. The documentation shows, using a test array with four entries, just how much this shortens with parallelism:

• Parallelism disabled: 21 seconds
• Degree of parallelism 2: 11 seconds
• Degree of parallelism 4: 6 seconds
• Degree of parallelism 6: 6 seconds

You can set the degree of parallelism between 1 and 50. Important: a high number doesn't automatically make everything faster, because splitting up the work, queuing additional threads, and delays from the called endpoint itself create overhead of their own. Nested Apply to each loops also always run sequentially — according to Microsoft, the parallelism setting only applies at the top level of the cloud flow.

Trigger concurrency — only with care

At the trigger level, you can additionally enable a concurrency control which sets how many instances of a flow may run at the same time; it's off by default. It helps with data sources that have limited throughput and prevents so-called dirty reads, where a flow keeps working with stale data because a parallel run changed the record in the meantime. However, Microsoft explicitly recommends caution: once enabled, the setting can't be reversed — only by recreating the trigger. As a best practice, the documentation recommends applying concurrency control only to a dedicated child flow with as few actions as possible, rather than to the entire main flow.

Lever 2: Reduce unnecessary actions and loops

Avoid nested loops

The guide on anti-patterns in cloud flows names nested Apply to each loops as one of the most expensive traps. Two loops with ten iterations each work out to 100 runs; with larger data volumes, this number grows exponentially and quickly hits the limits for iterations and total execution time. The documented alternative: use OData query expansion to load related records within a single query, instead of fetching them in a second, inner loop. A parameter like Products($select=ProductName,Price) replaces the entire inner loop with a single additional RetrieveMultiple call to Dataverse.

Trigger conditions instead of downstream checks

Many flows start on every change to a data source, even though only a fraction of the runs are actually relevant. A trigger condition, checked directly at the trigger, prevents these superfluous runs from happening in the first place, instead of catching them with an internal condition only after the flow has already started. That saves not just time, but also the action requests that would otherwise be consumed on every irrelevant run.

Batch and bulk operations instead of single actions

According to the documentation, if you need to create or update hundreds or thousands of records, you shouldn't process each record individually in a for-each loop. Batch operations combine several requests into a single HTTP request, while bulk operation web APIs in Dataverse go a step further: instead of many individual "Create row" actions, a single call to the CreateMultiple web API with 100 prepared records counts as just one action.

Lever 3: Choose the right connector and limit data volume

Load only the data you actually need

According to the guide Work only with relevant data the amount of data processed can be limited both at the trigger and at individual actions. For Dataverse sources, the parameters Select columns, Filter rows and Row count reduce the result set directly at the source. For SharePoint, Filter query, Top count and Limit columns by view serve the same purpose. This matters because so-called throughput limits cap how much data volume a cloud flow may read and write from its run history within a given period. If this limit is exceeded continuously for 14 days, Power Automate automatically turns the flow off.

The right action instead of the most convenient one

Choosing the right connector also means not automatically reaching for the most resource-intensive action for the same task. For example, data operations like Filter array, Select or Join process arrays directly and reduce the amount of data flowing through subsequent steps, often much more efficiently than an extra loop with conditions. Where a service offers native filter or selection parameters in the connector itself, Microsoft's documentation says it's more efficient to filter there instead of first loading the entire data volume into the flow and then reducing it with a separate data operation.

How to find the bottleneck in your own flow

The fastest way to find the actual root cause is with a fixed checklist. First, open the action analytics for the affected flow and check whether it's running close to its daily limits. Then check the run history for individual actions with unusually long runtimes — these are usually loops without parallelism, or actions loading unnecessarily large amounts of data. Also check whether errors of type 429 or 5xx show up, which point to limits from a connected service rather than Power Automate itself. For larger flow landscapes with several environments, structured Power Automate consulting is often worthwhile, going through parallelism, data volume, and connector choice systematically for all critical flows at once, instead of optimizing each flow individually.

Frequently asked questions

How many items should I process in parallel in an Apply to each loop?

There's no universal best value — Microsoft allows a degree of parallelism between 1 and 50. In the documented example measurement with four items, a parallelism of 4 already delivered the maximum speedup; increasing it further to 6 made no further difference to the runtime. In practice, it pays to start with a moderate value like 5 to 10 and watch the runtime in the run history, rather than setting the maximum value right away, because excessive parallelism can itself create delays caused by the called endpoint.

Does trigger concurrency control automatically improve performance?

Not automatically — Microsoft actually recommends restraint. The default setting without concurrency control allows as many simultaneous runs as the system can handle, which is already performant enough for most scenarios. Concurrency control mainly makes sense when a connected resource can only handle limited throughput or when dirty reads need to be prevented, not as a general speed-up measure. Since the setting can't be reversed, you should only apply it deliberately to a small, dedicated flow.

Why are nested loops such a big performance problem?

Because the number of runs multiplies instead of adding up. Two loops nested inside each other, each with ten items, result in 100 individual runs; with larger data volumes, this number keeps growing exponentially. That not only costs time, it also quickly pushes the flow toward the limits for iterations and total execution time, which in the worst case leads to flow errors or throttling.

What does connector choice have to do with performance when several connectors can do the same task?

Connectors often offer filter and selection parameters with different levels of granularity directly at the data source. A connector that already supports filtering, column selection, and a maximum row count at the trigger or action reduces the amount of data processed before it even reaches the flow. That has a direct effect on the throughput limits and lowers the risk that a flow gets throttled because of excessive data volume, or even automatically turned off after a sustained breach.

How do I tell whether a slow flow is caused by Power Automate or by the connected service?

A look at the error codes in the run history gives you the answer. Errors of type 429 or timeouts in the 5xx range point to protection limits of the connected service, which vary by connector. If, on the other hand, Power Automate itself reaches its daily action requests, the action analytics in "My flows" show this clearly, and owners also receive an automatic notification with tips on reducing the number of actions.