DEV Community: Sofiane Mebchour

Responsive Power Apps in 2026: Containers, Breakpoints and Wrap

Sofiane Mebchour — Fri, 16 Oct 2026 12:17:04 +0000

Many canvas apps pin every control to absolute X/Y coordinates at one design size, and look wrong at any other: a label overlapping a button on a laptop, dead space on a tablet, horizontal scrolling on a phone.

Power Apps has had proper responsive layout tools — horizontal and vertical layout containers — for several years. Here's how to build screens that adapt, and the limits worth knowing before you commit to a layout.

Why fixed positioning breaks

A control with X: 850, Y: 120, Width: 300 is correct for exactly one screen size. With Scale to fit on, Power Apps' answer to other sizes is to render your app at its design resolution and scale the whole thing like an image: text gets smaller, touch targets shrink, and a phone shows a miniature desktop app.

The alternative is real responsiveness: the app uses the actual window size, and your layout reflows. That takes two changes:

Settings > Display: turn off "Scale to fit". (Older Studio versions and some Microsoft pages call this area File > Settings > Screen size + orientation.) Turning it off also switches off and disables Lock aspect ratio. Lock orientation is a separate setting — turn it off too if the app should follow device rotation. With Scale to fit off, App.Width and App.Height change as the window is resized.
Stop positioning controls with absolute numbers, and let containers do it.

You could make every control's X/Y/Width a formula referencing Parent.Width — Microsoft documents that technique, including a centering pattern of the form (Parent.Width - C.Width) / 2, where C is the control being centered (the Self operator can stand in for its own name) — but a screen full of that math is miserable to maintain. Containers exist so you don't have to.

One testing caveat from Microsoft's documentation: the authoring canvas in Studio doesn't respond to these sizing formulas. Test in a published app, or in Preview — and if you resize the browser window while Preview is open, close and reopen Preview, because it may not update correctly.

Containers in 90 seconds

The controls that matter:

Horizontal container — lays out children left to right and manages their X for you.
Vertical container — lays out children top to bottom and manages their Y.
Container — a container in manual layout. Its children keep their own X/Y/Width/Height, so it groups and nests controls under a common parent but doesn't position them for you; responsiveness inside it still relies on formulas based on Parent.Width and Parent.Height.
Grid container — a newer control that places children by rows and columns. Microsoft's controls index has labelled it as preview, so check its status in your version of Studio before relying on it in production.

Inside a layout container, the children's position properties are taken over by the container. You stop thinking in coordinates and start thinking in structure. (Microsoft notes that drag and drop on the canvas is disabled inside layout containers: you reorder children in the Tree view or with the arrow keys, and controls moved into a container are inserted in their Tree-view order.)

Screen
└─ Vertical container (X 0, Y 0, Width Parent.Width, Height Parent.Height, Align (horizontal): Stretch)
   ├─ Horizontal container  ← header, fixed height 64
   ├─ Horizontal container  ← content, flexible height (Fill portions 1), Align (vertical): Stretch
   │  ├─ Vertical container ← sidebar, fixed width 280
   │  └─ Vertical container ← main area, flexible width (Fill portions 1)
   └─ Horizontal container  ← footer, fixed height 48

That's a classic app shell — header, sidebar, content, footer. The top-level container is sized to its parent (Microsoft's documented setup); everything inside it is laid out by the containers rather than by position formulas. Resize the window and the main area absorbs the change, while the header and footer keep their fixed height and the sidebar keeps its fixed width.

Fixed sizes vs Fill portions

Each child of a layout container sizes along the container's main axis in one of two ways:

Fixed size — "this button is 120 wide, always."
Flexible width / Flexible height with Fill portions — "give this child a share of whatever space is left."

Fill portions are relative weights over the container's extra space — the space left once the fixed children are placed. Two flexible children with portions 1 and 2 get one third and two thirds of it:

Horizontal container (width: Parent.Width)
├─ Gallery       flexible width, Fill portions: 2
└─ Detail panel  flexible width, Fill portions: 1

The pattern that makes real layouts work is mixing the two in one container: fixed sizes for chrome (icons, buttons, sidebars), flexible sizes for content. A search bar that fills the space between a fixed logo and a fixed avatar button:

Horizontal container
├─ Logo           fixed 140
├─ Search input   flexible width, Fill portions: 1
└─ Avatar button  fixed 48

On the cross axis, set the container's Align property to Stretch (Microsoft's walkthroughs label it Align (vertical) on a horizontal container and Align (horizontal) on a vertical one, but Studio labels vary between pages and versions — rely on the formula-bar name LayoutAlignItems, with values Start, Center, End and Stretch). A stretched vertical container inside a horizontal one is how you get equal-height columns without ever setting a Height.

Minimum sizes

Flexible children can get very narrow on a small screen, and fixed children can overflow it. The platform gives you two floors to set deliberately:

Per child: layout-container children have a Minimum width / Minimum height (LayoutMinWidth / LayoutMinHeight in the formula bar) — the minimum size of the child in the direction of the Fill portions.
Per app: the app has MinScreenWidth and MinScreenHeight. In Microsoft's responsive-layout page the default screen width is Max(App.Width, App.MinScreenWidth), so below that floor the screen stops shrinking and the user scrolls; another Microsoft page describes the formula as Max(App.Width, App.DesignWidth) once Scale to fit is off, so check the Width formula on your own screens.

Still plan the "too narrow" case explicitly with a breakpoint (next section): switch a container to vertical, or hide the element.

Breakpoints

There's no CSS media query in Power Apps, but there is built-in breakpoint support. Every screen has a Size property (ScreenSize.Small, Medium, Large, ExtraLarge) computed from App.SizeBreakpoints, which you can customize. Microsoft documents the defaults for tablet and web apps as [600, 900, 1200], and its own example uses it directly:

// A control's Visible property: show only from "Medium" up
Parent.Size >= ScreenSize.Medium

Inside a container, Parent is the container, not the screen — so reference the screen by name instead (for example HomeScreen.Size).

If you want your own thresholds, define them as named formulas in the App object's Formulas property (named formulas belong there, not in OnStart):

// App.Formulas
nfBreakpoint = If(App.Width < 640, "sm", App.Width < 1024, "md", "lg");
nfIsMobile = App.Width < 640;

A named formula is declarative: it updates when the values it depends on change, and App.Width changes as the window is resized. A Set() in OnStart runs once at startup and doesn't follow a resize. Resize a published app once to confirm it behaves that way in yours. (The 640 and 1024 above are illustrative, and they assume a tablet/web-format app — apps created in phone format use different default breakpoints, so check your own app's format.)

Then drive layout properties from the formula:

// A container's Direction (LayoutDirection in the formula bar): a two-column section
// that stacks on phones. Pick the values from the formula bar's suggestions if your
// Studio version names them differently.
If(nfIsMobile, LayoutDirection.Vertical, LayoutDirection.Horizontal)

// Sidebar container's Visible property: hidden on phones, shown from "md" up
nfBreakpoint <> "sm"

// Container padding: tighter on phones, wider elsewhere
// (set PaddingLeft and PaddingRight, or whichever sides you use)
If(nfIsMobile, 16, 40)

A context variable set once in Screen.OnVisible is the wrong tool here: it doesn't recalculate, so it won't follow a later window resize or a rotation.

Wrap

Horizontal and vertical containers both have a Wrap property. With wrap on, children that don't fit flow onto the next row (or column), which turns a container of fixed-width cards into a responsive card grid without positioning formulas:

Horizontal container (Wrap: on, Gap: 16, flexible height, vertical overflow: scroll)
├─ Card 1 (fixed 320)
├─ Card 2 (fixed 320)
├─ Card 3 (fixed 320)
└─ ...

Give the wrapping container flexible height and vertical scrolling — Microsoft's own wrapping recipe does the same — otherwise the wrapped rows can be clipped when the window is narrow. With 320-wide cards and a 16 gap, a row holds four cards once the container's inner width (its width minus padding) reaches 1,328 px (4 × 320 + 3 × 16), three from 992 px and two from 656 px; below that, expect one card per row. Those thresholds are derived from the sizes above, not figures from Microsoft's documentation. One documented limitation: when Wrap is on, the Align setting of the child controls is ignored.

Limits worth knowing

Spacing lives on the container. Use the container's Gap for spacing between children and its padding (PaddingTop, PaddingRight, PaddingBottom, PaddingLeft) for inset. Invisible spacer rectangles make layouts fragile.

Not every control works inside layout containers. Microsoft's known-issues list for auto-layout containers says that, at the time of writing, Data table, Charts and Add picture aren't supported inside them. Separately, the reference page for the Container control lists its own limitations: containers don't work within forms, and Data table, PDF viewer and Web barcode scanner aren't supported inside it. Check both pages before you design a screen around one of those controls.

Alignment edge cases. Besides Wrap ignoring the children's Align, Microsoft notes that Center or End justification combined with scrolling can leave children unreachable.

Galleries are sized like any other child of a layout container. To let a gallery take the remaining space, give it flexible height with Fill portions rather than a fixed height, and let the container own the size. Don't confuse this with the Flexible height gallery type, which is about items of variable height, and check the exact property names in your version of Studio.

Nest only as deep as the layout needs. Containers can be nested; each extra level is one more container to reason about when something doesn't resize as you expect.

A shorter checklist version of this — the settings, the container setup and the breakpoint pattern — is in the responsive containers guide.

Start from a working skeleton

Starting a responsive screen from a blank canvas is slow, and a reusable starting point removes much of that cost. Since Power Apps supports YAML copy-paste, a screen layout is a text snippet you can keep in a repo and paste into the tree view.

PowerBlocks has three free layout skeletons — a dashboard, a list/browse screen and a master-detail screen. To be precise about what they are: they're manual-layout containers whose X, Y, Width and Height are formulas based on the parent's size (mostly Parent.Width, some Parent.Height), mixed with a few fixed values — you paste them and fill each region with your own controls. They are not built on auto-layout containers or Fill portions, so the Direction, Gap and Wrap properties described above don't apply to them, and they don't ship with breakpoint formulas. To add one, drive each region's X, Y, Width, Height (and Visible) from a named formula such as nfIsMobile; the comments inside the YAML suggest setting a context variable in Screen.OnVisible, but as explained above a named formula is the better tool. Or rebuild the skeleton with auto-layout containers and use the pattern in this article — build it once, save the YAML, and never start a responsive screen from zero again.

Wrap-up

Turn off Scale to fit (Lock aspect ratio switches off with it; Lock orientation is separate) and reference App.Width, not pixels.
Structure screens as nested horizontal/vertical containers.
Fixed sizes for chrome, flexible sizes with Fill portions for content, Stretch on the cross axis.
Set minimum sizes deliberately: per-child LayoutMinWidth/LayoutMinHeight, per-app MinScreenWidth/MinScreenHeight.
Use Screen.Size / App.SizeBreakpoints, or named formulas in App.Formulas, for breakpoints — not a one-time variable.
Wrap gives you card grids without positioning formulas.
Check Microsoft's known-issues and limitations pages for unsupported controls before committing to a layout.

Are you building canvas apps with containers, or still on fixed X/Y? If something specific keeps you away from containers, tell me in the comments.

Power Automate Error Handling That Actually Works: 429, 404, Timeouts and Retries

Sofiane Mebchour — Thu, 01 Oct 2026 21:16:59 +0000

Most Power Automate flows are built for the happy path. They run fine in testing, fine for a few weeks in production, and then one morning there are 40 failed runs in the history and a business process quietly stopped working three days ago.

The failures are rarely exotic. A handful of HTTP status codes — 429, 404, 500, 401 — plus timeouts are among the most common causes of failed runs. Each one has a different cause and a different fix, and handling them properly is a modest amount of extra work per flow. Here's a pattern that covers all of them.

Step 0: actually read the error

Before any pattern, a habit: open run history, click the failed run, click the failing action, and read both the inputs and the raw outputs. The status code and message are right there, and they tell you which failure family you're in:

Code	Meaning	Typical cause
429	Too Many Requests	You exceeded a rate limit (the connector's or the underlying service's)
404	Not Found	The resource doesn't exist at that ID/path — deleted, renamed or moved, or the ID you sent was wrong (check the inputs for a value that came through empty)
500	Internal Server Error	The service hit a problem — often transient. Read the raw outputs; a request the service rejects as invalid is more typically a 400
401	Unauthorized	The connection can no longer authenticate
408 / ActionTimedOut	Request timeout / action timed out	A call exceeded its time limit (120 seconds for a synchronous request, or the timeout configured on the action); some timeouts surface as a 504 instead

The inputs matter as much as the outputs. Many 404s are solved by looking at the failing action's inputs and noticing the ID it actually used was empty — the dynamic content upstream had resolved to blank.

429: you're being throttled

Connectors, and the services behind them, enforce their own rate limits (the unit and the time window vary), and a 429 is how they tell you that you exceeded one. The classic way to hit them is an Apply to each that calls an action on every item of a list that grew from 50 items to 5,000 — especially once someone has turned concurrency up to make it faster.

Three levers:

1. Concurrency control. On the Apply to each → Settings → Concurrency Control. By default the loop runs its iterations one at a time; if concurrency has been turned on to speed it up (the degree of parallelism can go from 1 to 50), the loop can fire a burst of simultaneous calls at SharePoint or Outlook. In that case, lowering the degree of parallelism (or setting it to 1 for strict sequencing) is usually the fastest way to stop a 429 storm. The trade-off is runtime — which brings us to lever 2.

2. Fewer calls. The best API call is the one you don't make. Filter at the source with an OData Filter Query so the loop only receives rows that need processing, and use batch actions where the connector offers them instead of one call per row.

3. Retry policy with exponential backoff. For the 429s that still get through, configure the action's retry policy (action → Settings → Retry Policy). Example values — tune them to the service you're calling:

{
  "type": "exponential",
  "count": 5,
  "interval": "PT10S",
  "maximumInterval": "PT1H",
  "minimumInterval": "PT10S"
}

Exponential means the wait grows between attempts instead of staying fixed, which is exactly what a throttling service wants from you. Power Automate's default policy is already exponential, but its shape — notably the number of retries — depends on the flow's performance profile, so it isn't tuned to any particular service's rate limit; an explicit policy lets you choose the retry count and the minimum and maximum waits yourself. If a 429 response includes a Retry-After header, honor it: it tells you how long to wait before trying again (usually a number of seconds). The built-in HTTP action can use that header to space its retries (this is documented for the HTTP action in Azure Logic Apps, the engine cloud flows run on); for other actions, don't assume it — make sure your configured intervals aren't shorter than the delay the service asks for.

I go deeper on throttling causes and the delay-inside-loops technique in the 429 Too Many Requests guide.

404 and 500: different bugs, different fixes

These two get lumped together because they're both "the action failed", but they point in opposite directions.

404 = your reference is wrong. The record was deleted, the path points at the wrong site/environment, or a dynamic ID resolved to blank. Guard against it before the action instead of catching it after:

// Condition before the "Get item" action
@not(empty(triggerBody()?['ItemId']))

An empty value in a URL path often ends in a 404. One empty() check upstream is cheaper than any error handler. (empty() accepts strings, arrays and objects; if your ID arrives as a number, compare it with null instead: @not(equals(triggerBody()?['ItemId'], null)).)

500 = the service failed while handling your request. It is often a transient service-side incident — but some services also answer 500 to input they can't handle, such as a malformed JSON body or a null where a value was required. The fix is to read the raw outputs for the underlying message, validate your request body property by property, and — because some 500s really are transient — put a retry policy on the action. Retrying a 404 is pointless (the record won't materialize); retrying a 500 is often exactly right.

Full diagnosis walkthrough for both codes: Power Automate 404 and 500 errors.

Try/catch with Configure Run After

Power Automate has no try/catch keyword, but it has the mechanism: scopes + Configure run after. This is the skeleton worth putting in every non-trivial flow:

Scope: Try
  ├─ (all the real work)
Scope: Catch          ← Run after: "has failed", "has timed out"
  ├─ Compose: error details
  ├─ Post message / send mail to the team
Scope: Finally        ← Run after: succeeded, failed, skipped, timed out (all checked)
  ├─ (cleanup / logging that must always run)
Condition: Try didn't succeed        ← optional, top level of the flow, see below
  └─ Terminate: Failed, with a custom message

Set it up by adding the Catch scope after Try, then opening its Run after setting (new designer: select the scope, then Settings → Run after; classic designer: the three dots → Configure run after). Uncheck is successful and check has failed and has timed out.

Inside the Catch, pull the actual failure details rather than a generic "flow failed" message:

// Compose action — name, status, inputs and outputs of the Try scope's top-level actions
@result('Try')

// Filter array action — keep everything that neither succeeded nor was skipped
From:      @result('Try')
Condition: @and(not(equals(item()?['status'], 'Succeeded')), not(equals(item()?['status'], 'Skipped')))

result('Try') returns the name, status, inputs, outputs, timestamps and tracking IDs of the first-level actions of the scope. It does not drill into deeper nested actions (for example inside a Condition or a Switch). For a top-level action, that is enough to build a notification that says what failed and why (the service's error message is in the action's outputs), not just that something failed. If the failing call sits inside a loop or another nested container, the entry you get is the container itself: call result() on that loop's own name (as in Microsoft's result('For_each') example), or keep the actions you want to report on at the top level of the Try scope.

Filtering is done with the Filter array action; there is no filter() expression function. The condition above deliberately keeps "anything that isn't Succeeded or Skipped" rather than matching one exact string: Microsoft's documentation describes an action stopped by its timeout under more than one status, so this catches Failed, TimedOut and Cancelled alike. A flow that fails loudly with context gets fixed the same day; a flow that fails silently gets discovered a week later by the business.

One subtlety: if the Catch scope runs and handles the failure, the run is marked Succeeded. A run is only marked Failed when a failure isn't handled by a subsequent action. If you'd rather handled errors still show up as failed runs (so they're visible in monitoring), use a Terminate action set to Failed with a custom error message. Keep in mind that Terminate stops the run and skips every remaining action, so don't end the Catch with it if a Finally scope still has to run: put it after the Finally scope, inside a Condition that checks whether Try succeeded, for example @not(equals(actions('Try')?['status'], 'Succeeded')). Keep that Condition + Terminate at the top level of the flow: Terminate is documented as unusable inside Foreach and Until loops (documented for Azure Logic Apps — check that your designer accepts it before nesting it), so don't put it inside an Apply to each. If you'd rather the flow report success once the error is handled, skip the Terminate. Decide deliberately — the default surprises people.

401 / "connection expired": the slow-motion failure

This one deserves its own section because it doesn't fail on day one — it fails months later, after nothing changed in the flow.

Every connector action runs through a stored connection — a saved credential for that connector. When that credential expires, the account password changes, or consent is revoked, every action using that connection typically starts failing with an authentication error, most often a 401. The immediate fix is Power Automate → Connections → find the one showing an error → Fix connection and re-authenticate.

The real fix is structural:

Critical production flows shouldn't depend on the account of whoever built them. Run them under a dedicated identity: preferably a service principal (Microsoft's recommendation for critical or long-running flows; it is an unlicensed application user, so premium flows it owns need a Process or per-flow license), or otherwise a dedicated service account whose credentials aren't shared between people (Microsoft's FAQ advises against service accounts with shared credentials). Otherwise the flow breaks the day that person changes their password or leaves the company.
Check connection references when deploying through solutions. When you import a solution, you pick a connection for each connection reference. Without usable connections, the imported flow stays turned off, and if the importer picks their own connections, the flow runs under that account. Connection references are part of the deployment, not an afterthought.
After fixing a connection, open the flow, check that its actions show a healthy connection, and re-test it. If a trigger still doesn't fire, Microsoft's troubleshooting guide suggests making a small edit to the flow, saving it, reverting the edit and saving again so the trigger is registered again; other options are turning the flow off and on, or removing and re-adding the trigger.

I keep the checklist (including the password-policy angle for service accounts) in the connection expired guide.

Timeouts

Two distinct animals:

Action timeouts — a downstream call takes too long. On actions that support it (HTTP, connector and webhook actions, for example), you can set an explicit timeout (action → Settings → Action Timeout — labelled just Timeout in some designers — ISO 8601 duration such as PT5M) and combine it with the retry policy. Microsoft describes it as the maximum duration between retries and asynchronous responses for that action; it doesn't change the request timeout of a single request, so it doesn't extend the 2-minute limit on a single synchronous request. Your Catch scope should include has timed out in its run-after conditions — it's easy to configure only has failed and let timeouts slip past your error handling.
Flow-level limits — a cloud flow run can last up to 30 days, but a single synchronous HTTP request times out after 120 seconds (2 minutes); only asynchronous operations can be configured to wait longer. If a single action routinely brushes its timeout, the fix is architectural (webhooks / polling pattern), not a bigger timeout number.

The checklist

For every production flow:

Retry policy (exponential) on actions that call an external service, where the action supports one and repeating the call is safe.
Concurrency control tuned on every Apply to each that makes API calls.
Guard conditions before actions that take dynamic IDs (empty() checks).
Try/Catch scopes with run-after configured for failed and timed out, and a notification that includes result('Try') details.
A dedicated owner identity (preferably a service principal, otherwise a non-shared service account) and verified connection references before it ships.

None of this is glamorous, and all of it is the difference between automation people trust and automation people quietly work around.

Most of these guides live in the troubleshooting section of PowerBlocks, the Power Apps YAML component library I maintain — the flow-error write-ups are free, no login.

What's your Catch scope's notification channel — Teams, email, or a log table? And has anyone actually gotten a clean answer out of a bare 500 without reading raw outputs? Comments below.

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.