You built something useful in Power Apps, and now you're wondering whether you've pushed it too far. Maybe the delegation warnings won't go away, the galleries have gotten sluggish, or you've started copy-pasting the same formula across a dozen screens. The real question underneath all of it: is my app too complex for Power Apps, or is it just built in a way that needs cleaning up?
That distinction matters, because the two problems have very different fixes. This guide gives you an honest way to tell them apart: a self-diagnostic you can score in a few minutes, backed by Microsoft's actual, documented limits rather than vague warnings. By the end, you'll know whether your app is fine as-is, worth optimizing in place, or genuinely ready for a custom rebuild on the Microsoft stack.
The 60-Second Answer to "Is My App Too Complex for Power Apps?"
Here's the short version: an app is rarely too complex because of one dramatic limit. It's usually because you're pressing against several ceilings at once — data volume, business logic, integrations, and licensing cost — and the workarounds have started to cost more than they save.
So the honest test isn't "have I hit a limit?" Almost every non-trivial app brushes against one. The test is: how many hard walls are you hitting, and how hard? One delegation warning on a 300-row list is nothing. Delegation warnings plus 50,000-row aggregates plus a legacy-system integration plus five makers fighting over one app is a pattern — and the pattern, not any single number, is what tells you it's time to move.
Two tools below make that call concrete: a consolidated table of Microsoft's real limits, and a scorecard you can tally for your specific app.
First, What Power Apps Handles Well
Before we talk about ceilings, let's be clear about what Power Apps does genuinely well — because the goal is the right tool for the job, not a case against low-code. We build on the Power Platform for clients all the time, and for the right problem it's the fastest, most cost-effective option available.
Power Apps shines when the work is:
- Well-defined and single-department — approvals, requests, inspections, and simple trackers that replace a spreadsheet or paper form.
- Backed by data that mostly lives in Microsoft 365 — Dataverse, SharePoint, or Dynamics 365, where connectors are native and delegation support is strongest.
- Internal-facing, where the standard Power Apps look and feel is perfectly acceptable.
- Owned by a citizen developer or admin who can maintain it without a full engineering team.
If that describes your app, most "complexity" problems are solvable inside the platform. The apps that truly outgrow Power Apps pull in the opposite direction on several of those dimensions at once.
The 7 Complexity Ceilings: Power Apps Limitations for Complex Apps
These are the seven places where Power Apps performance at scale most often collides with real-world complexity. Each one is tied to a symptom you can recognize and a limit Microsoft actually publishes.
| # | Complexity ceiling | The symptom you'll notice | Microsoft's stated limit |
|---|---|---|---|
| 1 | Data & delegation | Delegation warnings; filters and searches that silently miss records | Non-delegable queries process 500 records locally by default, raisable to a 2,000 max; galleries page data in increments of ~100; Dataverse aggregates (Sum, Average, CountIf) cap at 50,000 rows |
| 2 | Complex business logic | The same formula copy-pasted across screens; logic you can't express cleanly | Power Fx is a declarative, Excel-like formula language — no traditional loops or recursion |
| 3 | Integrations | Fragile connections to legacy, on-prem, or non-Microsoft systems; throttling | Premium, on-prem, and custom connectors need standalone licenses; daily requests cap at ~6,000/user (Microsoft 365 & per-app) up to ~40,000/user (Power Apps Premium) |
| 4 | UI & branding | Can't nest lists deep enough; can't hit a pixel-perfect or customer-facing design | Galleries nest a maximum of 2 levels |
| 5 | Media & files | Images or video that won't upload; attachment limits | 64 MB per individual media file; 200 MB total media per app |
| 6 | ALM & collaboration | One person edits at a time; lost changes; painful versioning and deployment | Canvas apps are optimized for a single editor; multi-maker source control is limited |
| 7 | Cost at scale | Per-user premium licensing that grows with every rollout | Power Apps Premium ≈ $20/user/month ($12 with 2,000+ licenses); per-app ≈ $5/user/app/month |
Microsoft updates these limits and prices regularly. The figures above reflect Microsoft Learn's published limits as of mid-2026 — confirm the current numbers in Microsoft's delegation, gallery, media, request-limit, and Power Apps pricing documentation before you make a call based on them.
Three of these ceilings decide most cases, so they're worth a closer look.
Data and Delegation: the Power Apps Delegation Limit Most Apps Hit First
This is the wall we see most often. Power Apps tries to hand heavy lifting — filtering, sorting, aggregating — to the data source, a behavior called delegation. When a formula can't be delegated, Power Apps stops at the first 500 records by default (2,000 if you raise the Data row limit) and works on only that slice locally. On a 300-row list, that's invisible. On a 50,000-row table, your "search all customers" box quietly returns wrong answers. Dataverse and SQL Server delegate far more operations than SharePoint or Excel, so the same app can be healthy on one source and broken on another. If you've papered over delegation warnings with local collections, you're already managing around this ceiling.
Complex Business Logic: When Power Fx Runs Out of Room
Power Fx is deliberately Excel-like — declarative formulas, not a general-purpose programming language. It has no traditional loops and no recursion, which is fine for form logic and light calculations but painful for state machines, multi-step approval trees, or anything genuinely algorithmic. The tell isn't one impossible formula; it's formula sprawl — the same logic copy-pasted across a dozen controls and screens because there's no clean way to centralize it. That's Power Apps complex business logic bumping its ceiling, and it's a maintenance problem long before it's a functionality one.
Integrations and Request Limits: the Quiet Throttle
A single Microsoft 365 connector is easy. The strain shows when an app leans on legacy systems, on-premises databases, or non-Microsoft services — those need premium, on-prem, or custom connectors and the standalone licenses that come with them. There's also a daily ceiling: Power Platform caps API requests per user per 24 hours, commonly around 6,000 on Microsoft 365 and per-app licenses and roughly 40,000 on Power Apps Premium. A data-chatty app can brush that during a busy day, and it shows up as throttling rather than a clean error message. These request numbers change, so confirm the current allocations in Microsoft's request-limits documentation.
Score It: Is Your App Too Complex for Power Apps?
Now make it concrete. Score each signal below honestly — they map to the ceilings above — then add up your points. This won't replace an engineer's review, but it will tell you which conversation you're actually having.
| If this is true for your app… | Add |
|---|---|
| Your primary data source has well over 2,000 rows and users search or filter across all of it | 2 |
| You've worked around delegation warnings with local collections or capped result sets | 2 |
| Sum, Average, or Count totals come back wrong — or you've had to limit them — on large tables | 2 |
| You need loops, recursion, or logic Power Fx can't express, so formulas are copy-pasted across screens | 2 |
| The app depends on legacy, on-premises, or non-Microsoft systems | 1 |
| You've hit API throttling or daily request limits | 2 |
| The app must be pixel-perfect, branded, or customer-facing | 1 |
| Several makers need to edit it, and changes have been lost or overwritten | 1 |
| A media or file-size limit has blocked a feature you need | 1 |
| Premium per-user licensing has become a noticeable line item as you roll out | 1 |
Add up your score (maximum 15) and read the band:
- 0–4 — Not too complex. Power Apps is a reasonable home for this app. Fix issues as they appear; don't over-engineer.
- 5–9 — The build, not the platform, is probably the problem. You're hitting quality-of-implementation walls more than hard platform limits. Start with the next section before you consider a rebuild.
- 10–15 — Genuinely too complex for Power Apps. You're fighting the platform on several fronts at once. Plan the custom path described below.
Tip: drop this into a spreadsheet and have the whole team score independently. Where people disagree is usually where the real risk is hiding.
Before You Give Up on Power Apps: What You Can Still Fix
A high score doesn't automatically mean rebuild. In our experience, a large share of "too complex" apps are really under-optimized apps — the platform is fine, the build just grew organically. Before you budget a rebuild, exhaust these first:
- Rewrite non-delegable queries. Swap functions Power Apps can't delegate for ones it can, and push filtering to the server. This alone resolves most delegation problems.
- Move to Dataverse. Dataverse delegates far more operations than SharePoint or Excel and raises several ceilings at once. Migrating the data source is often the single highest-leverage fix.
- Refactor into components and Power Automate. Centralize copy-pasted logic into reusable components, and push heavy or scheduled processing into Power Automate flows or Azure Functions instead of formulas.
- Split one giant app into several. A single app doing five jobs is often five apps in a trench coat. Splitting by role or process restores performance and eases the single-editor bottleneck.
- Add the right premium connectors. Sometimes the "integration is impossible" problem is one licensed connector away from solved.
Sometimes the app isn't too complex — the build is. If a focused optimization pass clears your worst ceilings, you've just saved yourself a rebuild.
When Power Apps Is Not Enough: The Custom Path
When you've optimized and you're still fighting the platform — non-delegable data at real scale, algorithmic logic, deep legacy integration, or a customer-facing product — that's when Power Apps is not enough, and a custom build becomes the lower-risk option. The good news for a Microsoft-centric business: going custom does not mean leaving the Microsoft ecosystem or throwing away what you've built.
A typical rebuild path looks like this:
- Keep Dataverse (or your existing SQL/Dynamics data) as the system of record. Your data model and much of your logic carry forward — you're replacing the app layer, not the foundation.
- Rebuild the app in .NET on Azure, where there's no delegation limit, no formula ceiling, and full control over UI and branding.
- Move heavy logic into Azure Functions and orchestration into Logic Apps, so processing that strained Power Fx runs server-side at scale.
- Integrate legacy and non-Microsoft systems directly through APIs instead of connector workarounds.
- Phase it. We usually rebuild the highest-pain workflow first, run it alongside the existing Power App, and migrate incrementally — not a risky big-bang cutover.
This is the lane we work in every day: senior Microsoft developers, accelerated by our Human + AI delivery model, which has narrowed the old cost-and-timeline gap between low-code and custom enough that mid-market companies can realistically consider it.
A Real Example: the App That Hit the Wall
An illustrative scenario — a composite of the kind of engagements we see, not a specific client — shows how the pattern plays out.
A regional field-services company builds a Power App so technicians can log jobs, parts, and time on-site. For a year, it's a success. Then three things happen at once. The jobs table crosses 50,000 rows, so the "find any past job" search starts missing records behind delegation limits. Billing needs the data to flow into Dynamics 365, so the team starts maintaining manual exports. And the approval logic for multi-part jobs outgrows what Power Fx can express cleanly, leaving the same formula copied across screens.
Scored against the checklist, the app lands solidly in the 10-plus band — not one broken thing, but four ceilings at once. An optimization pass fixes the delegation issue by moving to Dataverse and rewriting queries, but the integration and logic ceilings remain. So the decision is a targeted rebuild: keep Dataverse as the system of record, move the app to .NET on Azure, run a proper API integration into Dynamics 365, and phase the cutover one workflow at a time. The Power App keeps running until each piece is replaced.
The point of the story isn't the specific numbers — it's the shape. Apps rarely fail on one limit. They accumulate ceilings until the workarounds cost more than the rebuild.
Frequently Asked Questions
How do I know if my app is too complex for Power Apps? Look for a pattern, not a single limit. If you're hitting several ceilings at once — persistent delegation warnings, aggregates that return wrong totals, logic you can't express without copy-pasting formulas, deep legacy integrations, and rising per-user licensing — the app has likely outgrown the platform. Score it against the checklist above; a total in the 10-plus band is a strong signal.
What is the Power Apps delegation limit, and why does it matter? When Power Apps can't delegate a query to the data source, it processes only the first 500 records locally by default, raisable to a 2,000-record maximum in app settings. It matters because past that point, filters and searches silently return incomplete results on large tables, so users can trust an answer that's actually wrong. Dataverse and SQL Server delegate more operations than SharePoint or Excel, so the same formula can behave differently depending on the source.
Can I fix a complex Power App without rebuilding it? Often, yes. Many apps labeled "too complex" are really under-optimized. Rewriting non-delegable queries, moving to Dataverse, centralizing logic into components and Power Automate, and splitting one overloaded app into several will resolve a large share of complexity problems without leaving the platform.
What are the signs I should move my app to custom development? The clearest signs are structural: real data scale that delegation can't serve, algorithmic logic Power Fx can't express, deep integration with legacy or non-Microsoft systems, a customer-facing product that needs full UI control, and licensing costs that keep climbing. When several of these persist after an honest optimization pass, custom development is usually the lower-risk path.
If I rebuild, do I have to leave the Microsoft ecosystem? No. A custom rebuild typically keeps Dataverse (or your existing SQL/Dynamics data) as the system of record and moves the app layer to .NET on Azure, with Azure Functions and Logic Apps for heavy logic. You get the headroom of custom development while staying on the Microsoft stack you already run.
Get a Free Power Apps Complexity Review
Still not sure which band your app falls in? We at Craftware will score it with you — for free. As a Microsoft Partner with 20+ years on the Microsoft stack, we'll walk your app through Microsoft's real limits, tell you honestly whether it can be optimized in place or needs a rebuild, and — if it's the latter — map the Microsoft-stack path to get there. There's no pressure to build anything; if Power Apps is still the right home for your app, we'll tell you that too. Book your free complexity review and get a clear next step before you commit budget either way.
