How can Power Automate be designed to process thousands of records without exceeding platform limits?

Processing thousands of records in Power Automate is fundamentally different from processing ten records.

A flow that works perfectly with:

50 records

can become slow, throttled or unreliable when processing:

50,000 records

The main mistake is to design the flow around individual actions instead of designing around data volume, API requests, pagination, concurrency and failure recovery.

Microsoft documents Power Automate request limits and notes that connector throttling can result in HTTP 429 Too Many Requests. It also points out that retries and pagination consume requests.

A simplistic design might be:

Get 10,000 Records
        |
        v
Apply to each
        |
        +---- Update record
        +---- Send email
        +---- Call API
        +---- Log

If every record causes several connector actions, the flow can generate a very large number of API requests.

First principle: reduce the number of records

Do not retrieve 100,000 records if only 5,000 require processing.

Filter at the source whenever possible.

Instead of:

Get everything
      |
      v
Filter in Power Automate

prefer:

Source
  |
  v
Filter at source
  |
  v
Return only required records

This reduces data transfer and downstream actions.

Pagination

Pagination is useful when a connector returns data in pages.

But pagination does not remove platform limits.

Microsoft documents limits on paginated items and notes that processing more data may require multiple flow runs.

Therefore:

Large Dataset
     |
     +---- Page 1
     +---- Page 2
     +---- Page 3
     +---- ...

should be deliberately designed rather than treated as unlimited processing.

Avoid unnecessary actions inside Apply to each

Suppose 20,000 records are returned.

If the loop contains five connector actions:

20,000 records
      ×
5 actions
      =
100,000 action executions

That is before considering retries, pagination and other flow operations.

Microsoft notes that actions inside an Apply to each contribute requests for each array item.

This is why set-based operations are often preferable.

For example, instead of:

Get records
   |
   v
For each record
   |
   +---- Update one record

look for a supported bulk or batch operation in the target system.

Concurrency

Power Automate supports concurrency controls for appropriate triggers and loops.

For Apply to each, Microsoft currently documents a configurable concurrency range up to 50, with 1 as the default. Trigger concurrency has its own settings and limits.

Increasing concurrency can improve throughput:

Sequential

Record 1 → Record 2 → Record 3 → Record 4

versus:

Parallel

Record 1 ─┐
Record 2 ─┤
Record 3 ─┼──→ Processing
Record 4 ─┤
Record 5 ─┘

But maximum concurrency is not automatically optimal.

Higher parallelism can increase:

• Connector throttling.
• Dataverse service protection pressure.
• API contention.
• Locking.
• Ordering problems.
• Downstream system load.

The correct concurrency level depends on the target connector and workload.

Dataverse deserves special attention

If the flow processes Dataverse records, remember that Dataverse has its own service protection limits. Microsoft notes that Dataverse service protection limits are evaluated per user associated with the action.

Therefore, increasing Power Automate concurrency does not magically remove Dataverse limits.

Better architecture for large workloads

A more mature architecture might look like:

Large Dataset
      |
      v
Filter at Source
      |
      v
Pagination / Partitioning
      |
      v
Batch Processing
      |
      +------------------+
      |                  |
      v                  v
Successful          Failed Items
Processing               |
      |                  v
      |             Retry Queue
      |                  |
      +--------<---------+
      |
      v
Monitoring / Reporting

For very large or mission-critical workloads, consider whether Power Automate should be the primary processing engine at all.

Depending on the requirement, alternatives may include:

• Dataverse bulk operations.
• Scheduled batch processing.
• Azure Functions.
• Azure Logic Apps.
• Dataflows.
• Integration middleware.
• Asynchronous messaging.

The correct choice depends on volume, latency, transaction requirements, retry requirements and operational ownership.

Error handling

Do not build a large flow where one failed record terminates the entire business process.

Consider:

Record
  |
  v
Process
  |
 +---- Success → Continue
 |
 +---- Failure
         |
         v
     Capture Error
         |
         v
     Retry / Review

A production flow should make it possible to answer:

• Which records succeeded?
• Which failed?
• Why did they fail?
• Can they be safely retried?
• Did the target operation partially succeed?
• Who is responsible for remediation?

The most important optimisation

The best optimisation is often not increasing concurrency.

It is reducing unnecessary work.

Before changing concurrency, ask:

Can I process fewer records?

Can I filter earlier?

Can I use one bulk operation instead of thousands of individual actions?

Can I move expensive processing to a more suitable service?

Can failed records be isolated instead of restarting the entire workload?

Power Automate is extremely useful for orchestration, approvals and business workflows, but large-scale processing requires deliberate engineering rather than simply placing thousands of records inside an Apply to each.

Power Automate can process thousands of records efficiently by using a batch-based and controlled-concurrency approach rather than processing all records at once. Use filters and pagination to retrieve only the records that actually need processing, process them in manageable batches, and configure controlled concurrency in Apply to each instead of setting maximum parallelism blindly. Minimize actions inside loops by retrieving related data in bulk where possible, use Dataverse bulk operations for high-volume updates, and implement status fields such as Pending, Processing, Completed, and Failed so the flow can resume from where it stopped. Finally, use appropriate retry policies for temporary throttling errors such as HTTP 429 and monitor API/request limits to prevent excessive calls and ensure reliable large-scale processing.