Power Apps 500 Record Limit: Change the Data Row Limit and Get More Than 2,000 Records

Megan Bowen runs our service desk, and she pinged me on a Monday morning: her Power Apps dashboard said there were 500 open and closed requests, but the SharePoint list behind it clearly had more. Nothing was broken. The app had simply stopped reading at row 500.

Most people go straight to the settings and raise the limit to 2,000. That works until the list grows past 2,000, and then the same silent cutoff comes back with no error message. Here’s what the limit really is, how I tested it on a 620-item list, and how I load every row.

Quick answer: The 500-record limit is the Data row limit for queries Power Apps can’t delegate, including ClearCollect and Collect from a data source. Change it under Settings > General > Data row limit (default 500, maximum 2,000). For more than 2,000 rows, use delegable filters, or collect the data in chunks by a delegable column such as a Choice, Number or Date column.

What is the Power Apps 500 record limit?

A data source is where the app’s data lives, here a SharePoint list. Delegation means Power Apps hands the query to that source, and the source sends back only the matching rows. When a formula can’t be delegated, Power Apps downloads the first 500 records and runs the formula on the device instead.

That cap is the app-wide data row limit. A record is one row, and a collection is a table the app keeps in memory. You’ll find more background on the Power Apps tutorials hub. The limit applies in two common places:

• Non-delegable formulas. A Filter that uses Len, Mid, If or Not on a SharePoint list, or functions like FirstN, Last, GroupBy and Choices. Power Apps marks these with a blue underline and a yellow warning triangle.
• Collections loaded from a data source. ClearCollect and Collect can’t be delegated, so they only copy the first portion of the source. That’s why creating a collection from a SharePoint list quietly stops at 500 rows.

Data already in memory, like collections and static Excel data, isn’t affected. Under 500 items any formula works, which is why many apps break only months after go-live.

Build the test app step by step

If you’ve never built a canvas app, follow these steps to make the same test app I used. You need a SharePoint list with more than 500 items.

1. Prepare the list. My Service Requests list on the SPGuides site has 620 items with IDs 1 to 620 and the columns Title, Status (a Choice: New, In Progress, Closed), Priority, Requester and DueDate.

2. Open the maker portal. Go to make.powerapps.com, stay on Home and select Start with design.

3. Create a blank canvas app. Under Create, pick Create from blank.

4. Choose the layout. In Start with a blank canvas, pick Tablet. Power Apps Studio, the editor, opens.

5. Add the data source. Select Add data, type SharePoint in the search box and pick the SharePoint connector.

6. Connect to the site. Paste the site URL, for example https://contoso.sharepoint.com/sites/SPGuides, and select Connect.

7. Pick the list. Check Service Requests and select Connect. The list now shows in the Data pane.

8. Add controls. From the Insert menu, add three Buttons, a few Text labels and a Vertical gallery. To give a control a formula, select it, pick the property (such as OnSelect) in the dropdown left of the fx formula bar, and type the formula.

To run the app, select the Play button at the top right, or hold Alt and click a button in the editor. Press Ctrl+S to save. Each label uses CountRows and Max(..., ID), the same way you count rows in a Power Apps collection.

What I saw on a 620-item SharePoint list

The first button, btnLoadSimple, has this OnSelect formula: ClearCollect(colRequests, 'Service Requests'). A gallery below is bound to colRequests. At the default limit, the label read 500 rows with the highest ID 500, and the gallery had 500 items loaded.

Requests 501 to 620 simply weren’t there, and no error appeared. In preview, the two chunked buttons (explained below) loaded all 620 rows at the same 500 limit:

Data row limit	ClearCollect whole list	Chunks by Status	Chunks by month (With)
1	1 row	3 rows	–
500	500 rows (highest ID 500)	620 rows	620 rows
2,000	620 rows	–	–

How to change the data row limit in Power Apps

In Power Apps Studio, follow these steps:

1. Select Settings on the command bar.
2. Stay on the General tab and scroll to Data row limit.
3. Enter a number from 1 to 2,000. The default is 500.
4. Close the dialog, save and publish, then rerun your load formula.

The description under the field reads “Set how many rows are retrieved from server-based connections where delegation is not supported.”

You can’t go above 2,000. It’s a hard maximum, not a license setting. Here’s the field at 2,000:

After I raised it and clicked the button again, colRequests held all 620 rows, and the gallery showed 620 items.

Why raising the limit to 2,000 isn’t the real fix

Microsoft keeps the default at 500 for performance. Every non-delegable query now pulls up to 2,000 rows over the network first. Wide lists with many columns feel it most, and so do users on phones.

The bigger problem is correctness. A count, average or search over a 5,000-item list still sees only the first 2,000 rows, and users take the partial answer as the whole one. The Power Apps CountRows function post shows how that plays out with counts.

Test your app with the data row limit set to 1

This is the trick I use before any app goes to production. Set the limit to 1, play the app, and watch every gallery, label and collection. Anything that isn’t delegated now returns a single record, so it stands out.

In my app, ClearCollect returned 1 row and the chunk-by-Status load returned 3 rows, one per chunk. That proves every Collect is capped by the limit too, so each chunk must stay under it.

Fix the flagged formulas first, for example by rewriting a filter on a SharePoint list with delegable operators. Then set the limit back to 500 or 2,000.

How to get more than 2,000 records in Power Apps

1. Delegate the query. The best fix is not to download everything. A gallery whose Items uses delegable Filter, Search or Sort works over any number of rows. For Choice columns, compare the subfield, as in Status.Value = "New"; getting a choice field value in Power Apps covers the syntax.

2. Load the data in chunks by Status. When you need the rows in a collection, collect them in pieces that each stay under the limit, filtered by a delegable column. My three statuses have about 207 rows each:

Clear(colAllRequests);
ForAll(["New", "In Progress", "Closed"] As s,
    Collect(colAllRequests, Filter('Service Requests', Status.Value = s.Value))
)

With the limit at 500, colAllRequests got all 620 rows. The As s part matters: inside Filter, ThisRecord refers to the list row, so the ForAll item needs its own name. More patterns are in the Power Apps ForAll function.

3. Load in chunks by month, with With(). Don’t chunk by ID ranges on SharePoint: Microsoft documents that ID only delegates with =. Date and Number columns delegate >= and <. My first try put the dates straight into the Filter:

Clear(colByMonth);
ForAll(Sequence(10) As m,
    Collect(colByMonth, Filter('Service Requests',
        DueDate >= Date(2026, m.Value, 1), DueDate < Date(2026, m.Value + 1, 1)))
)

That showed a delegation warning, with the underline on the Date(2026, m.Value, 1) parts, and returned only 1 row. In my test, Power Apps didn’t pass those loop-built dates to SharePoint as plain values.

The fix is to compute the dates first with With(), which names values before the Filter runs. The Filter then compares DueDate with plain dates, and the warning goes away:

Clear(colByMonth);
ForAll(Sequence(10) As m,
    With({monthStart: Date(2026, m.Value, 1), monthEnd: Date(2026, m.Value + 1, 1)},
        Collect(colByMonth, Filter('Service Requests', DueDate >= monthStart, DueDate < monthEnd))))

This version loaded all 620 rows into colByMonth with no warning. I use this With() trick any time a filter value depends on a loop variable.

4. Let a flow return the data. A flow called from the app can read the list with Get items and pagination turned on, then return the rows as JSON for ParseJSON. Pagination caps at 5,000 items (low tier) or 100,000. I explain the setup in retrieving SharePoint list data into Power Apps using Power Automate.

5. Use a view or Dataverse. A filtered SharePoint list view helps people browse, but it doesn’t change the Power Apps limit. Dataverse delegates more functions than SharePoint; see Dataverse vs SharePoint list for Power Apps.

What doesn’t help with the record limit

• A bigger gallery. Gallery size doesn’t change the limit. A gallery bound to a delegable formula already pages through the data as you scroll.
• Copying the list into a collection first. The copy itself is non-delegable, so the collection holds only the first 500 or 2,000 rows.
• Chunks larger than the limit. Each Collect is capped, so a chunk with 600 rows at a 500 limit loses 100 silently.

Common mistakes and how to fix them

• Counting with CountRows on a collection. It counts what was loaded, not what’s in the list.
• Using IsBlank in a SharePoint filter. IsBlank on a text column doesn’t delegate. Column = Blank() does, though it won’t treat an empty string as blank.
• Using Not or StartsWith on a Choice. Not doesn’t delegate to SharePoint, and neither does StartsWith on Choice or Lookup subfields.
• Building dates from the loop variable inside Filter. Move them into With() first, as shown above.
• Forgetting to rerun the load. Changing the setting doesn’t refresh existing collections. Click the button again.

Once your data loads completely, these collection guides are a good next step:

• Create Collection in Power Apps [With Examples]
• Add/Update Collection in Power Apps [With Various Examples]
• Power Apps Collection Distinct Filter [With Different Data Types]
• What Is Microsoft Dataverse? A Complete Guide for Power Apps Beginners

Frequently Asked Questions