The short version: Power Apps caps a non-delegable query at 500 records by default, as at 22 September 2026. A maker can raise that in Power Apps' own settings to a maximum of 2,000. Past that, the only real fix is a query the data source can run itself, called delegation, not a bigger number in the settings panel.
500 by default, 2,000 at the outside
| Setting | Value | Where it lives |
|---|---|---|
| Data row limit, default | 500 records | App Settings > General > Data row limit |
| Data row limit, maximum | 2,000 records | Same setting, raised by the maker |
| Recommended test value | 1 record | Forces every non-delegable formula to show up during testing |
| Delegable query ceiling | None, effectively | The data source runs the query and returns only the matching rows |
This is a Power Apps-side setting, not a data source limit. It only fires when a formula can't be pushed down to run on the server, which Microsoft calls a nondelegable query. When that happens, Power Apps pulls the first 500 rows to the device by default and runs the rest of the formula against that slice locally. Raise the Data row limit to 2,000 and it pulls more, but it is still a slice, not the whole table.
What it means for a firm under 20 staff
A small firm's tables are usually well under 500 rows for the first year or two, so a non-delegable Power Apps formula quietly works fine and nobody notices the limit exists. The problem shows up later, and it shows up as a wrong answer, not an error message. A job register that grows past 500 rows, a client list that hits 600, a stock count creeping toward 2,000: any of them can start silently dropping records out of a search, a filtered gallery or a count, and the app keeps running as if nothing changed. A canvas app with a non-delegable filter over 2,000 rows returns a partial result with no warning to the end user, only a small delegation warning triangle in the maker's own editor that most people learn to ignore.
The functions most likely to trip this on a SharePoint list are Search with certain patterns, several nested Or conditions across mixed column types, and sorting on some computed columns. Dataverse delegates a wider set of functions than SharePoint or Excel, which is the practical reason a table that outgrows SharePoint often gets rebuilt on Dataverse rather than just given a higher row limit.
The workaround, and its limit
Raising the Data row limit to 2,000 buys time on a table that's just crossed 500 rows, and it costs nothing beyond a small performance hit, since every non-delegable query now moves more data to the device before it runs. It does not fix a table that keeps growing. The durable fix is rewriting the formula to delegate: use Filter, Sort and LookUp with functions and operators the data source actually pushes down, rather than functions like FirstN, Concat or GroupBy that always run locally regardless of the row limit setting. Testing with the row limit set to 1, Microsoft's own recommendation, forces every non-delegable formula in the app to surface immediately instead of hiding until the data grows.
Where the ceiling is a licence question rather than a formula question, for example whether a bigger table needs Dataverse and what that costs a small tenant, the licence picker sorts what actually needs paying for from what doesn't.
Common questions
What is the Power Apps delegation limit by default?
500 records. When a query can't be delegated to the data source, Power Apps pulls the first 500 rows to the device and runs the rest of the formula locally. That's a ceiling on what the formula can see, not an error, so a filter or search can return a confident, complete-looking, wrong answer once the table passes 500 rows.
How do I raise the Data row limit in Power Apps, and what happens if I set it too high?
Open Settings, then General, then Data row limit, and set any value from 1 to 2,000. Raising it doesn't cost anything or need a different licence. It does cost performance: every non-delegable query now pulls more rows to the device before it runs, so a wide table with a high row limit can make the app feel sluggish, especially on a phone.
Does raising the delegation limit fix a slow app?
No, it just moves the wall from 500 to 2,000. The fix is delegating the query itself: swap the non-delegable function for a delegable one the data source supports, or split the work so the filtering happens on the server. Dataverse delegates more functions than SharePoint or Excel, which is usually the real reason a rebuild on Dataverse fixes an app that a higher row limit didn't.
Not sure if a delegation warning is safe to ignore?
Free 30-minute call. Send me the formula and the table size, and I'll tell you whether it's a row limit tweak or a rebuild.