Apply to each limits and pagination in Power Automate: The 100,000 threshold

When a flow in Power Automate suddenly fails with a cryptic error as soon as a SharePoint list, a Dataverse table, or an Excel range exceeds a certain size, one of the built-in loop and pagination limits is almost always behind it. The best known of these is the 100,000 limit for Apply to each loops and paginated items. In everyday use it stays invisible for a long time, because most lists are far smaller, and then it strikes exactly the processes that matter most: bulk imports, year-end closings, or the migration of large datasets.

This article explains which limits specifically apply to loops and pagination in Power Automate, how to enable pagination for an action, and which techniques let you reliably process even very large amounts of data without hitting the 100,000 iteration limit. All information comes from the official Microsoft documentation.

Which limits apply to loops and pagination?

Microsoft documents the relevant values in the overview Limits for automated, scheduled, and instant flows. The most important figures for a single flow run:

• Apply to each: 5,000 items in the Low performance profile, 100,000 items for all other profiles. This is the maximum number of array items an Apply to each loop can process.
• Paginated items: also 5,000 for Low, 100,000 for all other profiles. To process more items, you need to trigger multiple flow runs across your data.
• Split On: 5,000 for Low without trigger concurrency, 100,000 for all others without trigger concurrency, but only 100 as soon as trigger concurrency is enabled.
• Until iterations: 60 by default, 5,000 maximum.
• Apply to each (concurrency): the default value for simultaneously running iterations is 1, but it can be increased to a value between 1 and 50.

Which performance profile applies to your flow depends on its owner's license. Low affects, among others, free plans, Microsoft 365 plans, Power Apps Plan 1, and trial licenses, while premium, process, and per-flow licenses fall into the Medium or High profiles and can therefore use the full 100,000 limit.

The WorkflowRunActionRepetitionQuotaExceeded error

When an Apply to each loop hits its maximum iteration count, the flow fails with the error `WorkflowRunActionRepetitionQuotaExceeded`. According to the Cloud flow error code reference the most common causes are:

• a Get items or List rows action that returns all records instead of being filtered beforehand
• nested Apply to each loops whose iteration counts multiply, for example 100 times 100 equals 10,000 iterations
• a very large SharePoint list or Dataverse table that is loaded completely into a loop without a filter

As a remedy, Microsoft recommends narrowing down data already in the source action using OData filters such as `$filter` and `$top` instead of filtering only inside the loop, distributing large datasets across multiple flow runs using pagination tokens or date ranges, and using the Select or Filter array actions instead of a full Apply to each loop for pure transformations or filtering.

Enabling pagination for an action

For many data actions, such as List rows in Dataverse, pagination can be configured directly in the action settings. The Documentation on listing rows in flows describes the process in the new designer as follows:

1. Select the relevant action card, for example List rows.

2. Open the Settings tab on the left, and there Networking.

3. Set the Pagination toggle to On.

4. Enter the maximum number of desired rows under Threshold. The highest configurable threshold is 100,000.

Internally, Power Automate rounds this value up to full multiples of the default page size. For example, if you enter 7,000 and the page size is 5,000, 10,000 rows are actually returned. Without pagination enabled, the default limit of 5,000 rows applies automatically, and the response no longer contains an `@odata.nextLink` parameter once the threshold is exceeded.

Special case SharePoint: Get items and the 5,000 threshold

For the SharePoint action Get items, the default limit is even lower, at just 100 items, but it can be increased up to 5,000 via the advanced options and the Top Count parameter, before the list hits SharePoint's own view threshold. If you combine a filter query with a list that has more than 5,000 entries, it can happen that no results come back at all, even though matching records exist. Here too, enabling pagination in the action settings with a sufficiently high threshold provides a remedy, because Power Automate then retrieves the data in batches according to Top Count instead of only checking the first 5,000 unfiltered rows.

The action burst limit of 100,000 actions per 5 minutes

Besides the pure iteration count, there is a second, often overlooked brake: the action burst limit. According to the Guidelines for understanding platform limits the current upper limit is 100,000 actions per flow within a rolling five-minute window. Every action inside an Apply to each loop counts individually, so a loop with several actions per iteration reaches this limit much faster than the pure iteration count would suggest. Microsoft recommends distributing the load across multiple flows in such a case, for example using child flows (Child Flows) or trigger conditions that prevent unnecessary runs from the outset.

Processing large amounts of data cleanly: practical recommendations

For processes that can foreseeably come close to the 100,000 limit, a clear approach has proven itself in practice:

• Filter early instead of late: Narrow down records already in the source action using `$filter`, `$top`, or a SharePoint filter query, instead of loading the entire list into the loop and only checking it there.
• Avoid nesting: When you have several Apply to each loops nested inside each other, check whether the outer and inner iteration counts multiply, and build in Select or Filter array beforehand wherever possible instead.
• Distribute across multiple runs: Use skip tokens, date ranges, or a scheduled trigger to split a very large amount of data across multiple flow runs as planned, instead of processing everything in a single run.
• Use concurrency deliberately: If you increase the concurrency of an Apply to each loop to a value above 1, several iterations run at the same time, which saves runtime but increases the load on the connected systems and is therefore not sensible for every connector.
• Keep an eye on the limits: Regularly check the actual action count via Analytics on the flow details page instead of only reacting after an error occurs.

This approach keeps you in control of your data flow, instead of being caught off guard by a sudden failure in exactly the process that deserves the most attention anyway.

Who benefits from optimizing such bulk processes?

A single digital worker in Power Automate usually only hits the 100,000 limit once a company is really growing, for example when migrating a large legacy database, during annual reporting across all customer records, or when connecting an ERP system with several tens of thousands of line items. For such cases, a clean architecture made up of filtered source queries, sensibly sized pagination, and, where necessary, several consecutive flow runs pays off far more from the start than patching individual errors after the fact. Anyone who wants to build their Power Automate processes for large amounts of data robustly from the ground up will find support in NordFlux's Power Automate consulting.

Frequently asked questions

What happens if a flow needs to process more than 100,000 items?

Power Automate processes a maximum of 100,000 items per flow run in a single Apply to each loop or a paginated action. For larger amounts of data, Microsoft recommends triggering multiple flow runs across the data, for example using a skip token, a date filter, or a scheduled trigger that splits the processing into several portions.

Does the 100,000 limit apply equally to every license?

No. The limit of 100,000 applies to the Medium and High performance profiles, which include premium and process licenses among others. In the Low performance profile, which applies to free plans, Microsoft 365 plans, and trial licenses, the same limit is already 5,000 items.

How does the Apply to each limit differ from the Split On limit?

The Apply to each limit refers to a loop that iterates through an array within a single flow run. The Split On limit, on the other hand, affects triggers that deliver an array and split it directly into multiple separate workflow instances via a SplitOn property, instead of using a foreach loop. If trigger concurrency is additionally enabled for such a trigger, the Split On limit drops to 100 items.

How do I recognize that a flow is hitting the 100,000 limit?

The flow fails with the error `WorkflowRunActionRepetitionQuotaExceeded` as soon as an Apply to each loop exceeds its maximum iteration count. In the flow's run history, this error can be traced directly to the affected loop action, and via Analytics on the flow details page you can also see how many actions a run consumed in total.

Can I set the pagination threshold higher than 100,000?

No. According to Microsoft documentation, the maximum configurable threshold for pagination is 100,000, regardless of the value you enter in the settings field. Since it is rounded up internally to full page sizes, the number actually returned can be slightly higher than your entered value, but never above the 100,000 upper limit.

Sources: Microsoft Learn – Limits for automated, scheduled, and instant flows, Microsoft Learn – Understand platform limits and avoid throttling, Microsoft Learn – Use row lists in flows