Apply to each limits and pagination in Power Automate: how the 100,000 iteration limit works and how to work around it.
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.
Microsoft documents the relevant values in the overview Limits for automated, scheduled, and instant flows. The most important figures for a single flow run:
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.
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:
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.
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.
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.
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.
For processes that can foreseeably come close to the 100,000 limit, a clear approach has proven itself in practice:
$filter, $top, or a SharePoint filter query, instead of loading the entire list into the loop and only checking it there.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.
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.
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.
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.
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.
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.
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
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
"Auf alle anwenden" processes lists item by item and often appears unintentionally. How the loop works, why it slows things down, and when it can be removed.
Filter Array and Select replace Apply to Each for filtering and reshaping arrays and run noticeably faster.
Excel table, Apply to each, Outlook: how Power Automate sends a personal email to every row of your list.
The action burst limit and the 100,000 iteration limit hit processes with growing data volumes especially hard and often unexpectedly. NordFlux builds your bulk processes with pagination and clean error handling so they stay stable even as volume increases.