Scaling Power Platform with Azure: Patterns for When Low-Code Hits Its Ceiling

In brief. Power Platform is the right place to start most business applications, and its limits are predictable. When a solution reaches them, the answer is rarely a rebuild. Keep Dataverse and the apps your people use, and move only the high-volume or long-running work to Azure. This guide covers the warning signs, how to decide, five patterns that work, and the honest cost of running two platforms.

Outgrowing low-code is a sign of success

Power Platform lets organisations build working applications in weeks rather than months. Dataverse gives you a secure data model, model-driven apps give staff a consistent interface, and Power Automate connects it all without custom code. For most processes, that is all you need.

Some processes grow. Volumes rise, rules get more complex, and work that ran comfortably at a few hundred records a day now runs at hundreds of thousands. At that point, parts of the solution start to strain.

That is not evidence that low-code was the wrong choice. It means the solution became important enough to need more. The mistake is responding to it with a full rebuild, when usually only a small part of the solution has reached its limit.

Signs you've reached the ceiling

The symptoms show up in the business before anyone looks at the technology. This table pairs what people notice with what is usually happening underneath.

What the business notices	What is usually happening
Overnight processing finishes later each week, or spills into the working day	Flows processing records one at a time, or hitting daily request quotas
Jobs fail intermittently and someone has to rerun them by hand	Timeouts on long-running steps, or throttling when too many requests arrive at once
Licence or capacity costs rise faster than usage seems to justify	Automation consuming Power Platform request entitlements at scale
Staff wait for results before they can act	Batch processing that only finishes when the slowest item does
Every change to the process feels risky	Business logic spread across dozens of flows with no single view of the whole
Reporting depends on manual exports	Data copied out by flows or by hand rather than through a managed data route

One or two of these are worth watching. Three or more, recurring, usually mean a part of the solution needs to move.

Extend, don't replace

When a solution hits its ceiling, there are three broad options: optimise what you have, extend it with Azure, or replace the platform. Optimising should come first. Better filtering, fewer loops and bulk operations can buy a lot of headroom.

When optimising isn't enough, extending is almost always better than replacing. A simple rule guides it.

Power Platform is for people-facing work. Forms, views, approvals, business rules and the data model staff rely on all stay where they are, in Dataverse and the apps built on it.

Azure is for machine-scale work. High-volume processing, long-running jobs, complex orchestration and bulk data movement move to Azure services built for them, which read from and write back to Dataverse.

Users keep the same applications. The organisation keeps one system of record. Only the work that outgrew low-code changes home.

Four questions help decide what moves:

Volume. Will this process run at a scale that approaches the platform's limits, now or within a year?
Time. Does any single step need to run for longer than a few minutes?
Coordination. Do many steps need to run in parallel, wait on each other or recover from partial failure?
Skills. Does the organisation, or its partner, have the skills to build and support Azure components?

If the answer to the first three is no, stay in low-code. If the answer to the fourth is no, factor support into the decision before extending.

The limits behind the symptoms

For architects and engineers. Figures are Microsoft's published defaults at the time of writing; they vary by licence and environment and can change.

Dataverse service protection limits. By default, each user is limited to 6,000 requests and 20 minutes of combined execution time in a 5-minute sliding window, and 52 concurrent requests, per web server. Exceeding them returns HTTP 429 with a Retry-After header. (Microsoft Learn)
Plug-in execution. A Dataverse message operation, including all its registered plug-ins, has a hard two-minute limit. Microsoft recommends keeping plug-in execution to around two seconds. (Microsoft Learn)
Power Automate. Outbound synchronous requests time out after 120 seconds. "Apply to each" runs sequentially by default, with concurrency configurable up to 50. Daily request quotas range from 10,000 to 500,000 depending on the licence's performance profile. (Microsoft Learn)
Request entitlements. Each licensed user and application user has a daily allocation of Power Platform requests, which high-volume automation consumes quickly. (Microsoft Learn)

None of these limits is unreasonable. They exist to keep a shared platform stable. They do mean that some workloads belong elsewhere.

Five patterns for extending Power Platform with Azure

Each pattern starts with when you would need it, so it is useful even if you skip the technical detail.

1. Orchestrating high-volume, dependent work with Durable Functions

When you need it: a process involves many steps, some of which depend on others, at a volume where running them one by one takes too long.

Azure Durable Functions lets you write orchestration as code. An orchestrator fans work out to activity functions that run in parallel, waits for the results it needs, and continues. Sub-orchestrations break a large job into independent units, such as one per record or sample, so each can finish and report on its own. Orchestrators checkpoint their progress, so work survives restarts without starting again.

Trade-offs: orchestrator code must be deterministic, which takes some discipline. Monitoring needs to be set up deliberately, and writes back to Dataverse must respect service protection limits.

In practice: When Power Automate Hit Its Ceiling: Scaling to 400,000 Validations a Day describes moving a validation engine from Power Automate to Durable Functions, with results available as each sample completed.

2. Absorbing spikes and decoupling with Azure Service Bus

When you need it: events in Dataverse need to trigger work elsewhere, volumes arrive in bursts, and you don't want users or plug-ins waiting for the downstream work to finish.

Dataverse can post events directly to Azure Service Bus through a registered service endpoint, sending the execution context of a create, update or custom message to a queue or topic. Consumers in Azure process the messages at their own pace. A spike becomes a longer queue rather than a wave of timeouts.

Trade-offs: processing becomes eventually consistent, so the UI must not assume work is finished. Consumers must be idempotent, because a message can arrive more than once, and dead-lettered messages need an owner.

3. Moving long-running processing out of plug-ins and flows

When you need it: a step routinely takes longer than a plug-in or flow allows, such as document generation, calling a slow external system or heavy calculation.

Keep the plug-in thin. It validates the request and hands the work off, usually through a queue. An Azure Function or a containerised service on Azure Container Apps does the heavy lifting and writes the result back to Dataverse. Users see a status that updates when the work is done.

Trade-offs: another hosting component to deploy, secure and monitor. Write-backs need retry logic that honours the Retry-After header.

4. Getting data to analytics without exports

When you need it: reporting or data science depends on copying Dataverse data out, by hand or by flow.

Azure Synapse Link for Dataverse continuously exports selected tables to Azure Data Lake Storage, and Link to Microsoft Fabric offers a similar route into Fabric. Either replaces fragile extract flows with a managed, near-real-time route into the data platform.

Trade-offs: storage and analytics compute have their own costs, and data arrives near real time rather than instantly. Governance of the exported data needs the same care as the source.

5. Loading and updating data at volume with bulk operations

When you need it: integrations or migrations create or update thousands of records at a time and hit throttling or run for hours.

Dataverse's bulk operation messages, CreateMultiple, UpdateMultiple and UpsertMultiple, process many rows in one request. Combined with parallel requests from an Azure Function or integration service, they raise throughput substantially while staying within platform limits.

Trade-offs: on standard tables, one failed row rolls back the whole request, so batch sizes and error handling need thought. A bulk request counts as one request for service protection, but every row still counts towards request entitlements.

The honest cost of running two platforms

Extending with Azure solves real problems, and it adds responsibilities. They are manageable, but they should be planned for rather than discovered.

Skills. Someone needs to build and support .NET or similar code, not just low-code. If that capability doesn't exist in-house, it needs to come from a partner, with a support model agreed up front.

Deployment and change. Power Platform solutions and Azure components each have their own deployment route. Both need source control and automated pipelines, released together, so a change to one doesn't break the other.

Monitoring. A problem might sit in a flow, a plug-in or an Azure Function. Application Insights, plug-in trace logs and flow run history should be correlated so one investigation covers the whole path.

Security. Azure components should connect to Dataverse as application users, authenticated with managed identities rather than stored secrets, and with only the permissions they need.

Cost. Azure consumption costs are usually modest for bursty workloads, but they are a new line in the budget. Model them alongside any savings in Power Platform licensing or capacity.

Case studies in this guide

When Power Automate Hit Its Ceiling: Scaling to 400,000 Validations a Day. Orchestrating dependent validations with Durable Functions, with results available sample by sample.

More case studies covering the other patterns will follow.

Not sure where your solution's ceiling is?

Start by listing your three busiest automated processes, with their daily volumes and how long each takes to run. Compare them with the limits above. That usually shows where the pressure will come from first.

If you'd like help assessing your Power Platform solution and planning where Azure fits, get in touch.