What it does

A view defines which columns appear for a table, in what order and width, with what default sort and filter. The grid control decides how that view is rendered — read-only or editable, paged or infinitely scrolled, grouped, aggregated, or reflowed into cards on a narrow screen.

Key facts

• Three view types. Personal views are owned by a user and private unless shared. Public views are general-purpose, available to all app users through the view selector, and usable in subgrids and dashboards. System views are special-purpose and the app depends on them.
• The system views are Quick Find, Advanced Find, Associated and Lookup. They don't appear in the view selector, can't be used in subgrids or dashboard lists, and can't be deleted or deactivated. Quick Find also defines which columns are searched.
• The Advanced Find view defines the default columns used when a new public or personal view is created without a template.
• System views are cached for performance, so plug-ins on the savedquery table aren't supported.
• Users can create personal views if they have at least User-level access on the Saved View table. You can create a personal view from a public or system view, but not a public or system view from a personal one.
• Custom public views can be deleted in an unmanaged solution. System-defined public views can't be deleted; managed-solution public views should be removed by updating or uninstalling the solution.
• The Power Apps grid control is the current grid and is set to replace all others. The Power Apps read-only grid, the legacy editable grid and the legacy read-only grid are all marked deprecated.
• Power Apps grid capabilities: infinite scroll (select up to 1,000 rows), inline editing, nested grids, grouping on a single column, aggregation (sum, min, max, average) on numeric columns, filtering, sorting, column reordering, range selection, jump bar, choice-column colours, and a customiser control hook.
• Grid defaults worth knowing: Enable editing No, Enable filtering Yes, Enable sorting Yes, Enable grouping No, Enable aggregation No, Allow column reordering No, Enable multiselect Yes, Allow range selection Yes, Enable jump bar No, Enable pagination No (so infinite scroll is the default), Reflow behaviour Reflow.
• Grouping isn't supported when paging is enabled, and grouping isn't offered on lookup columns.
• Configuring the Power Apps grid control at table level applies it to all views for that table.

When to use / skip

Public views are the cheapest UX win in the whole product — a well-named set of five or six views per table removes most of the "I can't find my records" support traffic. Editable grids are the opposite: they look like a productivity feature and behave like a data-quality risk, because business rules, form scripts and required-field logic that live on the form don't apply in the grid. Use them for genuine bulk edits of simple columns and keep them off anything with validation behind it. Grouping and aggregation are worth turning on for supervisor-facing views and worth leaving off elsewhere, because they invite people to treat the grid as a reporting tool.

Configuration decisions

• Which public views each app includes per table, rather than shipping every view that exists.
• Whether the grid is editable, and at what scope — table-level applies everywhere, view-level is narrower.
• Infinite scroll or paging. Paging kills grouping; infinite scroll kills Select all.
• Whether users get filtering, sorting, grouping, aggregation and column reordering, or a locked-down grid.
• Default sort and filter on each view, which is what most users will ever experience of the view.
• Whether personal views are allowed at all, controlled through Saved View privileges on the security role.

Gotchas

• Views retrieve what you put on them. A view with twenty columns including several lookups is a slow view, and users will blame the app.
• A user with read-only access to the main list who navigates through a form to a subgrid they can write to still can't edit — access is evaluated on the main entity first.
• Lookup column filters using Equals or Does not equal only offer values present in the currently filtered data. This differs from older grids and reads as a bug to users.
• Duplicate rows in the dataset may not display in the grid, so the reported record count can exceed what's visible, and exports can show more rows than the grid did. This applies to all grid controls.
• Card list view — what the grid reflows into on narrow screens — drops sort, Select all, the jump bar and all images. Users on tablets get a materially different experience.
• Editable-grid lookup cell customisation isn't supported, and events may not fire uniformly when the grid is read-only at table level but editable for some views.
• Choice-column colours need checking for contrast before you enable them, or you've made an accessibility problem.

Consultant notes

• Name views the way the business talks, not the way the data model is shaped. "My open cases this week" beats "Active Cases — Owner Filtered".
• Audit inherited environments for deprecated grid controls. Legacy read-only and editable grids are on the way out and it's better to migrate on your schedule than Microsoft's.
• Be direct with clients who ask for editable grids everywhere: it bypasses the validation you've built on the form. Offer it where the data is simple and refuse it where it isn't.
• Personal views quietly become the client's real reporting layer. Decide early whether that's acceptable or whether the Saved View privileges get restricted.
• Test every view on a tablet-width window before sign-off. The reflow to cards surprises people at UAT.

---

Worth revisiting once the deprecated grid controls are actually removed, or if grouping picks up lookup column support.