Power Apps 2,000 vs 10,000 Rows: Delegation Explained

Power Apps makers have long planned around a 2,000-row maximum for the canvas app data row limit. Some Microsoft documentation now refers to 10,000. Does that mean a gallery can safely process every record in a large SharePoint list? No: the critical question is whether the complete query delegates to its data source.

What Microsoft currently says about the limit

As reviewed on 10 November 2026, Microsoft’s delegation overview describes a default of 500 and a setting from 1 to 2,000. Its canvas data sources guide and data payload guidance describe a maximum of 10,000. These published pages conflict; they do not by themselves establish which maximum is available in every app or why the discrepancy exists.

In a nonproduction copy of your app, open Settings → General → Data row limit and check which values the editor accepts and retains. Confirm behavior with a controlled test, not just the field’s appearance. Treat any larger value as an app-specific observation; it does not establish global availability. Raising the limit can increase transfer, memory use and load time.

What delegation means

A delegable formula translates into a query the connected source can execute. The source filters or sorts its data, and the app receives the results, often in pages for a directly bound gallery. A nondelegable query instead evaluates a limited retrieved subset locally. If matching records fall outside that subset, the app may show an incomplete result without a runtime error.

For example, with a 100,000-item source and a nondelegable query limited to 2,000 retrieved rows, matching records outside that subset may be omitted. Even if 10,000 is available and selected, the remaining records are not guaranteed to be evaluated. The source’s retrieval order should not be assumed to correspond to the business order or to an ID range.

Example: SharePoint text filtering

Assume Employees is a SharePoint list and Title is a single-line text column. These are illustrative formulas; verify them against your connector, schema and app:

Filter(Employees, Len(Title) > 5)

Len applied to the source column is not delegable in this SharePoint example. A large list can therefore produce partial results. The following is a different business question—a prefix search—not an equivalent replacement for a length test:

Filter(Employees, StartsWith(Title, "John"))

Microsoft’s SharePoint delegation table documents StartsWith for supported text columns. Verify the complete expression and column type; for example, SharePoint does not delegate StartsWith on Choice or Lookup subfields. If the business requirement truly is title length, redesign it using a maintained source-side field or another supported server-side approach, with appropriate ownership and testing.

Connector and column details matter

SharePoint’s list view threshold is a separate source-side concern from the app’s nondelegable data row limit. Delegation alone does not guarantee a large-list query avoids that threshold; design selective filters and appropriate indexes, and verify the actual behavior with the list owner.

Counts, collections and bulk changes

CountRows and CountIf have source-specific behavior. Microsoft says SharePoint counts in canvas apps are not delegated. For Dataverse, enhanced delegation is required for supported counts; filtered counts have a 50,000-row aggregate limit, while an unfiltered CountRows can use a periodically updated cached count. See Microsoft’s count function guidance before treating a displayed count as exact.

ClearCollect is nondelegable: it is useful for genuinely small, bounded reference data but should not be treated as a way to copy an arbitrarily large source. Microsoft also documents special simulated delegation behavior for UpdateIf and RemoveIf; their operation and affected row count depend on the connector, configured limit and local cache. Do not use them as an assumed unlimited bulk update. Plan safe, authorized batch operations and verify outcomes.

How to test a large-data query

1. Use a representative test source: create enough synthetic records to exceed the configured row limit. Place identifiable matching and nonmatching records across the dataset and maintain an independent expected result.
2. Inspect the formula: review delegation warnings and the connector’s table for every operator, column type and source. Absence of a warning is not proof of delegation.
3. Test with a low limit: Microsoft recommends temporarily setting the data row limit to 1 in a test copy to expose nondelegable expressions. Restore the intended value afterward.
4. Compare with the source: verify known matching records and expected counts using an appropriate source-side method. Test representative users and permissions, not only the maker account.
5. Inspect requests and performance: use Power Apps Monitor and source diagnostics where available to inspect operations, failures, paging and timing. Test realistic device and network conditions.
6. Document the result: record the app version, connector, column types, setting, test data, expected and observed results, and any source-side limits. Retest after changes.

Practical design checklist

• Start with a selective, delegable source query and return the columns users need.
• Check the entire formula and source-specific restrictions before adding transformations.
• Avoid loading large sources into collections solely to bypass delegation.
• Distinguish the local row setting from source thresholds, paging and aggregate limits.
• Measure correctness and performance using data beyond the configured limit.
• Review current documentation and the actual app setting before relying on a numerical maximum.

Walkthrough: searching a large employee list

Suppose a SharePoint list contains 100,000 employee directory entries and the app needs a prefix search on a single-line text Title column. Create a test list with synthetic data and connect it directly to a gallery. The following illustration uses a literal search value to keep the comparison simple:

Filter(Employees, StartsWith(Title, "John"))

First verify that the column is the expected text type and the connector supports this expression. Then ask the list owner for an independent source-side list of expected matches, using a method appropriate for the list and user permissions. Compare specific expected records with the gallery and scroll to request additional pages. Verify results with at least two users whose permissions differ, because the authorized result set may differ.

Now compare the original requirement with Filter(Employees, Len(Title) > 5). This second query asks a different question and is nondelegable in the SharePoint example. If the first locally retrieved subset contains only some qualifying records, the gallery may appear plausible while omitting others. A larger local row limit can make the test look better without proving it complete.

A repeatable test matrix

Do not assume that a record with a high SharePoint ID must lie outside the locally retrieved subset: the source determines retrieval order unless an appropriate supported order is specified. An independent expected result and inspection of actual requests are stronger evidence than guessing from ID alone.

How to investigate a delegation warning

1. Identify the exact formula and data source. Determine which part of the expression the warning identifies.
2. Check the connector’s delegation table for the operator and the actual column type. Check nested functions, lookup fields and sort operations as well as the outer Filter.
3. Ask whether the requirement can be expressed with a supported server-side operation. A different function may change the business meaning, so compare expected results before replacing it.
4. If a derived value is essential, consider storing and maintaining it in the source or using an appropriate server-side service. Agree on update, permissions and consistency responsibilities.
5. Retest with a source larger than the configured local limit, compare against independent results, and inspect the request in Monitor where available.

Warnings are useful signals, but they are not a complete audit. Microsoft notes that warnings are only shown for delegable data sources, and local collections can hide the origin of a partial dataset. Verify both the query that creates a collection and the formulas that consume it.

Common questions behind incomplete results

“The matching list has fewer than 2,000 rows. Why are some missing?” For a nondelegable filter, the local limit concerns the subset retrieved for evaluation, not a promise to find that many matches across the whole source. Matches outside the retrieved subset may never be considered.

“My gallery scrolls past 2,000 items. Is delegation working everywhere?” Paging a gallery bound to a delegable source can retrieve additional results, but it does not prove that a separate count, collection, search or bulk update delegates. Review each formula independently.

“Can I use a collection to cache the entire list?” A collection is local, and a nondelegable ClearCollect can retrieve only a limited portion. Caching may be appropriate for a small bounded lookup table; it should not be assumed complete for an unbounded directory.

“Can I set the limit to 10,000 and ignore warnings?” Even where that setting is available, a larger local subset does not guarantee full results beyond the configured limit. It can also increase download and processing costs. Check the current app, connector and workload.

Choosing a strategy for larger workloads

For interactive browsing, start with selective delegable filters and incremental gallery loading. For counts or reporting, assess the source’s supported aggregates and their accuracy and limits. For bulk changes, use a purpose-designed and authorized server-side or batch process when appropriate, and verify its results. For complex search or derived fields, consider source-side indexing or a maintained search structure rather than transferring an entire table to the client.

Each approach has tradeoffs in permissions, freshness, operating cost and maintenance. Establish the required correctness and expected data growth first, then test the chosen design with representative records and users.