What it does

The controls that bind to a data source and repeat: Gallery for lists, Display and Edit form for single records, Data table for tabular read-only output, plus the modern Data Grid and the preview Table control. Everything about canvas app performance eventually comes back to how these are configured.

Key facts

• Galleries nest to two levels. You can't put a gallery inside a gallery that is itself already inside one.
• Several controls aren't supported inside a gallery: Display form, Edit form, PDF viewer, Power BI tile, Rich text editor, the scrollable (fluid grid) screen, and the web barcode scanner.
• AllItems and AllItemsCount reflect only the rows currently loaded, which can be fewer than the data source holds. More load as the user scrolls. Treat them as a view, not a count.
• DelayItemLoading holds row loading until after the screen first renders; LoadingSpinner and LoadingSpinnerColor cover the gap visually. Both are documented performance levers.
• The Flexible height gallery has a known scroll problem: scroll before loading finishes and the item in view can be pushed out of view when it completes. Microsoft's advice is to use a standard gallery instead.
• Minimum TemplateSize is 1, which can push child controls off their expected X or Y if you don't account for it.
• A ComboBox, DatePicker, Slider or Toggle inside a gallery with an OnChange that patches the same data source the gallery is bound to can create a patch-and-reload loop. Don't put OnChange rules on those controls inside a gallery.
• Reset() on a gallery doesn't recursively reset its child controls.
• For screen readers: AccessibleLabel describes the list, ItemAccessibleLabel describes each row, and Selectable determines whether the gallery is announced as a selectable list.

When to use / skip

Gallery for anything the user browses or picks from, Edit form for anything they submit, and put the form on its own screen rather than fighting the "no forms in galleries" rule. Data table and the modern Data Grid earn their place when the user genuinely wants a grid — dense, sortable, many columns — and not when someone just wants a list to look like Excel. If the requirement is really "let them edit forty rows at once", that's a model-driven editable grid conversation, or it's a spreadsheet, and either way it isn't a canvas gallery.

Configuration decisions

• Whether the gallery filters server-side through a delegable expression or pulls a set and filters locally, because that decision is the app's performance ceiling.
• Whether to use DelayItemLoading on screens with several galleries, and what the user sees during the delay.
• Standard gallery versus flexible height, given the documented scroll behaviour on the latter.
• Whether editing happens in a form control or through Patch against controls you laid out yourself — the second is more work and more control, and gets chosen too casually.
• How selection state is held: the gallery's Selected, a variable, or a context record passed to the next screen.

Gotchas

• Nested galleries hit the two-level limit sooner than people expect, because a gallery inside a component inside a gallery still counts.
• AllItemsCount looks like a row count and isn't. People build "showing X of Y" labels on it and get numbers that change as the user scrolls.
• The OnChange-patching loop inside galleries doesn't fail loudly. It shows up as an app that gets slower the longer it's open.
• Forms can't go inside galleries, which drives a lot of otherwise odd screen designs. Plan navigation around it rather than discovering it mid-build.
• After the February 2026 modern control updates, OnChange on modern Text Input fires on blur rather than per keystroke. Gallery search boxes built on OnChange behave differently — reference the control's Text property directly instead.

Consultant notes

• Test galleries against production-sized data, not the fifty demo rows. Delegation problems and load behaviour are invisible below the delegation limit and obvious above it.
• When a client asks for an "editable grid" in a canvas app, find out whether they mean bulk edit or just faster single-record entry. The second is a screen design problem; the first is usually the wrong platform choice.
• The two-level nesting limit is worth mentioning in design workshops. It quietly rules out a few layouts people sketch on whiteboards.
• Set AccessibleLabel and ItemAccessibleLabel as you build galleries, not at the end. Retrofitting them across a finished app is the least enjoyable accessibility work there is.

---

Worth revisiting when the modern Table control leaves preview, or if gallery nesting limits ever change.