DEV Community: Sofiane Mebchour

Delegation in Power Apps, Explained With Real Queries

Sofiane Mebchour — Wed, 16 Sep 2026 22:03:01 +0000

If you've built more than two canvas apps, you've seen it: the blue squiggly underline in the formula bar, a yellow warning triangle, and a message about "delegation". Most makers hover it once, shrug, and move on — until a user reports that a record they know exists doesn't show up in the app.

That missing record is delegation. It's the single most common source of "the app is losing data" bugs in Power Apps, and it's entirely predictable once you understand what's happening under the hood.

What delegation actually is

When your gallery's Items property says:

Filter(Orders, Status = "Open")

there are two ways Power Apps can evaluate it:

Server-side (delegated): Power Apps translates your Power Fx into a query the data source understands (OData for SharePoint, FetchXML-ish for Dataverse, SQL for... SQL) and sends it over the wire. The server filters its million rows and returns only the matches. Fast, complete, correct.
Client-side (not delegated): Power Apps can't translate part of the formula, so it downloads rows from the source and runs the filter locally on your device.

Here's the trap: in case 2, Power Apps does not download the whole table. It downloads the first 500 rows (the default data row limit, configurable up to 2000) and runs your formula on that subset only.

So Filter(Orders, Status = "Open") against a 10,000-row SharePoint list with a non-delegable condition doesn't error out. It returns the open orders among the first 500 rows — and silently ignores the other 9,500. No error message. No empty gallery. Just quietly wrong results.

That's what the blue underline is warning you about. It's not a style suggestion. It's "your query will return incomplete data on large tables."

The 500/2000 limit

The cap for non-delegable queries lives in Settings > General > "Data row limit for non-delegable queries". Default is 500, maximum is 2000.

Raising it to 2000 is a legitimate move when your table genuinely stays small — a reference list of 800 categories, say. But treat it as what it is: a stopgap. At row 2001 the bug comes back, and pulling 2000 rows on every screen load hurts performance on mobile. I wrote up the setting and its trade-offs in more detail in this guide on the data row limit.

The durable fix is always the same: make the query delegable so the cap never applies.

Delegation depends on the data source

This is the part most tutorials skip: delegability is per connector, per function, per operator. The same formula can be fully delegable against Dataverse and non-delegable against SharePoint.

Rough hierarchy, from most to least delegation support:

Dataverse — the widest support: Filter, Sort, LookUp, comparison operators, StartsWith, And/Or/Not, aggregates like Sum/CountRows in many cases.
SQL Server — very good: most comparisons, StartsWith, sorting.
SharePoint — noticeably narrower: =, <, >, StartsWith are fine, but Search, in on text, IsBlank in filters, and sorting by complex column types are not delegable. Choice and lookup columns have extra quirks.
Excel / imported static data — essentially nothing delegates. Fine for lookup tables under 500 rows, dangerous for anything else.

Practical consequence: if you're choosing a backend for a table that will grow past a couple thousand rows and you're on SharePoint "because it's free", delegation is the tax you'll pay. It's manageable — but only if you write your formulas around it.

Real queries that break, and their delegable rewrites

1. Search vs StartsWith

// ❌ Not delegable on SharePoint
Filter(Orders, Search(CustomerName, txtSearch.Text) > 0)

// ❌ Also not delegable on SharePoint (the "in" operator on text)
Filter(Orders, txtSearch.Text in CustomerName)

// ✅ Delegable
Filter(Orders, StartsWith(CustomerName, txtSearch.Text))

Yes, StartsWith only matches from the beginning of the string. For a search box, that's usually acceptable — and it's infinitely better than a "contains" search that only searches the first 500 rows.

2. Functions inside the filter condition

// ❌ Not delegable — the source can't evaluate Text() or Year()
Filter(Orders, Text(OrderDate, "yyyy") = "2026")

// ✅ Delegable — compare against plain values the server understands
Filter(Orders, OrderDate >= Date(2026, 1, 1), OrderDate < Date(2027, 1, 1))

The rule of thumb: the column stays naked on the left side. The moment you wrap the column in a function (Text(), Lower(), Year(), arithmetic), the server can't translate it and evaluation falls back to the client.

Same idea with computed values — pre-compute them into a variable before the query:

// ❌ Function call evaluated per-row inside the filter
Filter(Tasks, DueDate < DateAdd(Today(), 7, TimeUnit.Days))

// ✅ Compute once, filter on the plain value
Set(varWeekOut, DateAdd(Today(), 7, TimeUnit.Days));
Filter(Tasks, DueDate < varWeekOut)

(Whether the first version delegates varies by connector — the second version removes the doubt everywhere.)

3. LookUp on a non-delegable condition

// ❌ IsBlank inside a filter is not delegable on SharePoint
LookUp(Orders, IsBlank(ClosedDate))

// ✅ Compare to Blank() directly (delegable on most sources)
LookUp(Orders, ClosedDate = Blank())

4. Filter server-side first, then do the fancy stuff locally

You don't have to make everything delegable — you have to make the part that touches the big table delegable. Once the result set is small, client-side evaluation is harmless:

// Delegable date-range filter reduces 50,000 rows to ~200,
// then the non-delegable sort runs safely on the small result
SortByColumns(
    Filter(Orders, OrderDate >= varMonthStart, OrderDate < varMonthEnd),
    "CustomerName",
    SortOrder.Ascending
)

This "narrow on the server, refine on the client" pattern solves 80% of real-world delegation problems without any exotic workaround.

The collections workaround (and its caveats)

The classic hack for "I need all 8,000 rows locally" is chunked ClearCollect:

ClearCollect(colAll, Filter(Orders, ID >= 1, ID <= 2000));
Collect(colAll, Filter(Orders, ID >= 2001, ID <= 4000));
Collect(colAll, Filter(Orders, ID >= 4001, ID <= 6000));
Collect(colAll, Filter(Orders, ID >= 6001, ID <= 8000));

Each chunk is a delegable query under the row limit, so you end up with the full table in a collection. It works. I've used it. And you should know exactly what you're signing up for:

It's a snapshot. The collection is stale the moment it's built; edits by other users won't appear until you re-collect.
Load time and memory. Thousands of rows over the wire on app start, on every device.
The ID ranges are a maintenance trap. Gaps are fine, but growth isn't — at row 8,001 you're silently dropping data again, which is the exact bug you were trying to fix.
It caps out. Somewhere in the tens of thousands of rows this stops being viable at all.

Use it for genuinely bounded, read-mostly datasets (a product catalog, a location list). For anything that grows unbounded, fix the query instead — or move the table to Dataverse where the query can delegate.

A workflow that keeps you honest

Never ignore the blue underline. Hover it — Studio tells you which part of the formula is non-delegable.
Test with realistic volume. Delegation bugs are invisible with 50 test rows. Load 1,000+ rows before you trust a screen.
Know your connector's delegable list. Check Microsoft's per-connector documentation when in doubt — SharePoint's list is short enough to memorize.
Keep the column bare on the left side of every comparison inside Filter/LookUp.

I keep a fuller checklist of fixes in the delegation warning guide — it's the write-up I send to teammates when the blue underline shows up in a code review.

Wrap-up

Delegation isn't a Power Apps quirk to memorize around — it's the fundamental question of where your query runs. Server-side means complete and fast; client-side means the first 500-2000 rows and a silent data bug. Write filters the server can translate, narrow before you refine, and treat the row limit setting as a last resort.

For quick syntax reference while rewriting formulas (including the delegable-friendly patterns above, in both EN and FR locale syntax), I maintain a free Power Fx expression cheatsheet as part of PowerBlocks, my Power Apps component library — no login needed.

What's the nastiest delegation bug you've shipped to production? Share yours in the comments.

The Power Fx Formulas You Actually Use Every Day (With French Locale Gotchas)

Sofiane Mebchour — Mon, 14 Sep 2026 13:23:52 +0000

Every Power Apps maker ends up googling the same formulas over and over. This is the cheatsheet I wish I had — organized by what you're actually trying to do, not alphabetically: filtering galleries, validating forms, saving data with Patch, dates, state, and (the part most tutorials skip) the French locale traps that silently break copy-pasted formulas.

And because half my projects run in French environments: the locale gotchas that silently break copy-pasted formulas, which almost no English tutorial mentions.

1. Filtering a gallery (the big one)

// Basic filter
Filter(Orders, Status = "Open")

// Search-as-you-type (delegable)
Filter(Orders, StartsWith(CustomerName, SearchInput.Text))

// Combine search + dropdown filter
Filter(Orders,
  StartsWith(CustomerName, SearchInput.Text),
  ddStatus.Selected.Value = "All" || Status = ddStatus.Selected.Value
)

// Sort the result
SortByColumns(Filter(Orders, Status = "Open"), "OrderDate", SortOrder.Descending)

Delegation tip: prefer StartsWith() over Search() and in on large sources — non-delegable functions silently cap your results at 500-2000 rows.

2. Validating a form

// Required field + email shape
If(
  IsBlank(txtEmail.Text) || !IsMatch(txtEmail.Text, Match.Email),
  Notify("Please enter a valid email", NotificationType.Error),
  SubmitForm(EditForm1)
)

// Disable the submit button until valid
DisplayMode: If(
  !IsBlank(txtName.Text) && IsMatch(txtEmail.Text, Match.Email),
  DisplayMode.Edit,
  DisplayMode.Disabled
)

Key functions: IsBlank(), IsMatch(), IsError(), Coalesce() (first non-blank value).

3. Saving data with Patch

// Create a record
Patch(Orders, Defaults(Orders), {
  Title: txtTitle.Text,
  Quantity: Value(txtQty.Text),
  DueDate: dpDue.SelectedDate
})

// Update the selected gallery item
Patch(Orders, galOrders.Selected, { Status: "Closed" })

// Create or update in one formula (upsert)
Patch(Orders,
  Coalesce(LookUp(Orders, ID = varID), Defaults(Orders)),
  { Title: txtTitle.Text }
)

The #1 Patch trap: type mismatches. Value(), Text(), DateValue() are your friends — a text input is always text, even if it looks like a number.

4. Dates without tears

Today()                              // date only
Now()                                // date + time
Text(Today(), "dd/mm/yyyy")          // format for display
DateAdd(Today(), -30, TimeUnit.Days) // 30 days ago
DateDiff(StartDate, EndDate, TimeUnit.Days)

5. Variables and collections

Set(varUser, User().Email)                   // global variable
UpdateContext({locShowModal: true})          // screen variable
ClearCollect(colItems, Filter(Orders, ...))  // snapshot a query
With({t: Filter(Orders, Status="Open")},     // scoped, no variable at all
  CountRows(t) & " open / " & Sum(t, Amount) & " €"
)

With() is the most underused function in Power Apps — it replaces most "temporary variable" needs and keeps formulas readable.

6. The French locale gotchas 🇫🇷

If your formula works in a US tenant and throws syntax errors in a French one, here's why:

Argument separators change. In fr-FR, Power Fx uses ; between arguments (because , is the decimal separator):

// en-US
Filter(Orders, Status = "Open", Amount > 100)

// fr-FR — same formula
Filter(Orders; Status = "Open"; Amount > 100)

Chained statements use ;; in French where English uses ;:

// en-US:  Set(x, 1); Notify("done")
// fr-FR:  Set(x; 1);; Notify("terminé")

Decimals flip too: 0.5 (EN) becomes 0,5 (FR) inside formulas.

So a YAML snippet or blog formula written for EN will not paste cleanly into an FR-locale Studio session. Either convert the separators, or keep two variants of your snippets. (I wrote a small converter as part of PowerBlocks — the cheatsheet tool shows every formula in both EN and FR syntax, and it's free.)

The full searchable list

This article covers the formulas I use daily, but the full reference — 80+ functions with EN/FR examples, searchable and filterable by category, one-click copy — lives here: Expression Cheatsheet on PowerBlocks (free, no login). There's a Power Automate equivalent too.

What's the formula you always have to look up? Drop it in the comments — I'll add the most requested ones to the cheatsheet.

Power Apps YAML Components: Build Canvas App UIs by Copy-Pasting Code

Sofiane Mebchour — Sun, 05 Jul 2026 07:49:46 +0000

If you build canvas apps in Power Apps, you've probably rebuilt the same modal, search bar, or navigation header a dozen times by hand. There's a better way: since Microsoft introduced YAML support in Power Apps Studio, entire UI components can be copied and pasted as plain text — controls, layout, formulas and all.

This changes how you can work: components become shareable snippets, reviewable in Git, and reusable across every app and tenant.

What is Power Apps YAML?

Power Apps Studio serializes canvas controls in a YAML-based format (the same format used by Power Apps Source Code files, .pa.yaml). When you copy a control in the Studio tree view, what lands in your clipboard is YAML. The reverse works too: paste valid YAML into the tree view, and Studio recreates the whole control hierarchy.

A minimal example — a styled button:

- PrimaryButton:
    Control: Classic/Button
    Properties:
      Text: ="Save changes"
      Fill: =RGBA(59, 130, 246, 1)
      Color: =RGBA(255, 255, 255, 1)
      Height: =40
      Width: =160
      BorderRadius: =8

Paste that into any screen's tree view (Ctrl+V) and you get a working button. Now imagine the same thing for a complete confirmation modal, a data table, or an entire screen layout.

How do you paste a YAML component into Power Apps?

Copy the YAML snippet (from a file, a repo, or a component library).
In Power Apps Studio, open the Tree view and select the screen (or container) where the component should go.
Paste with Ctrl+V (Cmd+V on Mac).
Studio instantiates the controls. If a control version differs from your environment, let Studio auto-upgrade it.

That's it — no import wizard, no solution packaging, no component library setup.

Common pitfalls (and how to avoid them)

French/localized environments use semicolons. Power Fx separates function arguments with , in English locales but ; in French and several other European locales. YAML written for an EN environment will throw formula errors in an FR environment. Fix: keep two variants of your snippets, or convert separators before pasting.

Native control versions differ per environment. Wrappers around native controls (date pickers, combo boxes) reference a control version like GroupContainer@1.3.0. If your environment runs a different version, accept Studio's auto-upgrade prompt.

Names must be unique per screen. Pasting the same component twice auto-renames controls (Button1_1), which can break formulas referencing them by name. Prefer components whose internal references are relative.

Not everything serializes. Data source connections and some component-library references don't travel through the clipboard — YAML components work best as pure UI + Power Fx logic.

Where to find ready-made YAML components

You can build your own snippet library in a Git repo — that alone is a big win for teams. If you want a head start, PowerBlocks is a curated library of copy-paste ready Power Apps YAML components (modals, forms, navigation, tables, cards), each with EN/FR locale variants and usage instructions. The component library includes free components, and the site also ships free developer tools:

an Expression Cheatsheet covering Power Apps functions with EN/FR examples,
an RGBA Color Picker that outputs ready-to-use RGBA() formulas,
an Icon Library with copy-ready Icon.Name expressions.

Why this matters for Power Platform teams

Copy-paste YAML turns canvas app UI into code you can govern: store components in a repo, review changes in pull requests, enforce a design system through shared snippets, and onboard new makers with a paste instead of a tutorial. For solution architects, it's the missing link between low-code speed and pro-code discipline.

If you've been maintaining screenshots-and-instructions documentation for your team's UI patterns, replace it with a folder of .pa.yaml files — your future self will thank you.

Do you already version your canvas app components as YAML? I'd love to hear how your team handles reuse across environments — drop a comment.