Table Patterns
Ten gallery-based table screens, one technique each. Built from standard controls, so there are no components to install. Each runs on sample rows the moment you paste it, and every query is written the way SharePoint needs, so it keeps working past 5,000 items. Take the one that matches the job, or combine two.
10 patterns · one .msapp · no components
Two parts to paste
The screen YAML, and the shared App.Formulas block once per app.
No components needed
Standard controls only. Nothing to import or keep updated.
Runs before it is wired
Sixty sample rows until you point it at a list.
Start here
Sortable, searchable and filterable, with every query written to delegate. The other nine are this plus one technique.
Acting on rows
When people change or choose rows rather than only reading them.
A lot of rows
Keeping a long list usable, and staying inside what SharePoint will answer.
Fitting the screen
The same rows, laid out for the space they have.
Why they still work on a big list
Each rule below came from a query that worked on a demo list and stopped working on a real one. They are applied in all ten screens, so switching a pattern to SharePoint is renaming the source rather than rewriting the filters — and all ten were checked against a real 6,000-item SharePoint list with no delegation warnings, status chips included. Every screen that searches or filters also says when nothing matches, with a button to clear them.
- Filters delegate. Equality on an indexed column and StartsWith on text. Never in, Search() or <>.
- “All” sends no condition. The If sits outside the Filter and tests the key with IsBlank.
- One literal sort per column. A column name in a variable does not delegate, so a Switch picks one.
- Index before 5,000. Past that, SharePoint refuses an unindexed filter or sort outright.