Almanac
Microsoft/power-appsPower Platform

Consultant KB for Microsoft Power Apps: canvas apps, model-driven apps, Power Fx, data and connections, controls and UI, code and extensibility, mobile and offline, ALM and solutions, governance and security, licensing and performance, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Apps release plans, docs repo and product blog, plus the author's own consultant notes.

feature-delegation.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn

What it does

Delegation is Power Apps translating your Power Fx query into an equivalent query the data source runs itself, so filtering and sorting happen at the server and only the matching rows come back. When any part of an expression can't be translated, none of it is delegated and the app processes the query locally over a capped slice of records.

Key facts

  • The local processing cap defaults to 500 records. You can set Data row limit in app settings anywhere from 1 to 2,000. That's the whole range — there is no higher setting.
  • If any part of a query expression is non-delegable, Power Apps delegates none of it. It's all or nothing per expression.
  • Delegation support is per data source, not global. Dataverse, SharePoint, SQL Server and Salesforce all publish their own delegable function tables, and they differ.
  • Filter, Search, First, LookUp, Sort and SortByColumns are the delegable query functions. FirstN, Last, LastN, Choices, Concat, Collect, ClearCollect, GroupBy and Ungroup are not.
  • If, multiplication, division, Mod, Concatenate and the & operator, ExactIn, casting with Text or Value, and all the string manipulation functions block delegation everywhere.
  • With, UpdateContext and Set create collections internally. Collections are in-memory and can't delegate — and you get no delegation warning for it.
  • Delegation warnings only appear on formulas that use a delegable data source. No warning on a non-delegable source doesn't mean the query is fine.
  • Query expressions are limited to two lookup levels (one for offline), and you can expand or join up to 20 entities in a single query.

When to use / skip

Delegation isn't optional on any table that will grow. The honest test is whether you'd be comfortable if the table hit a million rows, because the failure mode isn't an error — it's silently correct-looking wrong answers. Small reference tables under 500 rows genuinely don't need it, and pretending otherwise wastes design effort. Everything else does, and the time to establish that is at data model design, not when a user reports that a search stopped finding things.

Configuration decisions

  • What the Data row limit is set to. Setting it to 1 during build makes every non-delegable expression obvious immediately, which is the cheapest testing technique available.
  • Which side of the equality operator holds the entity property, because Dataverse only delegates when it's on the left.
  • Whether awkward queries get solved with a server-side view, a Dataverse action, or a flow, rather than by raising the row limit.
  • How much filtering happens in the data source versus in the gallery Items formula.

Gotchas

  • Raising the limit to 2,000 is the most common bad fix on the platform. It hides the problem until the table passes 2,000 rows, usually months after go-live and after the consultant has left.
  • SharePoint ID columns display as numbers but are text underneath, so only = delegates on them. Relational comparisons quietly fall back to local.
  • UpdateIf and RemoveIf simulate delegation by pulling records down in batches. They look delegated and behave like a local operation, and the number of rows actually touched depends on what's already cached.
  • Aggregates are the quietest failure. An Average over a million-row table returns the average of the first 500 records with no visible sign that anything went wrong.
  • Filtering on a related table's column, like PrimaryContact.Fullname in [...], isn't delegated even though the same operator on a base column is.

Consultant notes

  • Make delegation a data model conversation, not a formula conversation. Most delegation problems are really "this shouldn't have been a SharePoint list" problems.
  • Show the client the failure mode once, with a table of 600 rows, before they choose a data source. Watching a search miss a record is more persuasive than any slide.
  • Put "row limit set to 1 in dev, warnings triaged" in your build standards and check it at code review. Retrofitting delegation across a finished app is a rewrite.
  • Warn the client that delegation support changes over time as connectors are updated. A formula that warns today may not warn next year, and vice versa.

Worth rechecking the per-connector delegable function tables each release wave — they do change.

Was this accurate?