6.2 Creating and Configuring Views for Model-Driven Apps
Key Takeaways
- Public views are visible to all app users, system views (Quick Find, Lookup, Advanced Find, Associated) serve special platform purposes, and personal views are created by individual users
- Only the Quick Find view's find columns are searched when a user types in a grid search box — adding a column to a view's layout does not make it searchable
- Personal views are shared with specific users or teams using granular access rights such as Read, Write, Delete, Append, Assign, and Share
- Adding the editable grid control to a table or subgrid enables in-line editing, but composite columns such as Full Name, Customer lookups, and party lists stay non-editable
- Makers decide which views appear in an app's view selector by including them in the app designer, and each table has exactly one default view per app
Views decide which records users see in a table's grid and what those rows look like. The AB-410 exam tests the taxonomy of views, the mechanics of editing them, and a handful of sharp traps around search and sharing.
View Types
| Category | Examples | Who sees it |
|---|---|---|
| Public views | Active Accounts, My Active Accounts | Every app user (subject to record-level security) |
| System views | Quick Find, Lookup, Advanced Find, Associated | Special-purpose views the platform itself relies on |
| Personal views | Anything a user saves for themselves | The creator and anyone it is explicitly shared with |
Public and system views are defined by makers and administrators; personal views are created by end users through the modern advanced find experience. Each system view has a job: Quick Find drives search behavior, the Lookup view drives record pickers, Advanced Find is the template for user-built queries, and Associated views render related-record grids.
Editing Columns, Sort, and Filters
Makers edit views at make.powerapps.com under Tables → Views, and end users get a lighter in-app editor through Edit filters and Edit columns in the view selector. In both experiences you can:
- Add, remove, reorder, and resize columns — including columns from related tables, which is how you show an account's primary contact email on the contact grid.
- Set the sort order with a primary and a secondary sort column.
- Build filters from field conditions grouped with AND/OR logic. Filters can traverse relationships, so you can show contacts whose parent account is in a given industry.
Changes to a public view must be published before users see them, and the modern editors generate the underlying FetchXML for you — no query language is required of a maker. Views are solution-aware, so they travel with the table when you move customizations between environments.
Default View and the App's View Selector
Each table has one default view per app — the grid users land on first. In the app designer you also choose exactly which of a table's views the app exposes; the runtime view selector lists only those included views plus the personal views available to the current user. This is an easy exam point: if a view is not added to the app, it does not appear in the selector even though it exists on the table. System views such as Quick Find and Lookup never appear in the selector — they power specific platform behaviors instead of being browsable lists.
Quick Find and Lookup Views
The Quick Find view defines what happens when a user types into the search box above a grid. Its find columns are the columns actually searched, and they are configured separately from the view's display columns. Dataverse indexes find columns in the background after you add them, which keeps search fast; stuffing in many rarely used find columns wastes that indexing and slows results. Exam trap: adding a column to a view's layout does not make it searchable — you must add it as a find column on the Quick Find view. The Lookup view controls the record picker users see when selecting a related record; customize its columns so users can tell two contacts with the same name apart, for example by adding email or city.
Editable Grids
Grids are read-only by default — on phones and tablets the platform explicitly applies a Read-only grid control. To enable in-line editing you add the Editable grid control, either at the table level (where it applies across web, phone, and tablet form factors) or on an individual subgrid on a form. Editable grids support in-cell editing, grouping, and nested grids, but not every column participates: composite columns such as Full Name, Customer lookups, and party-list columns stay non-editable, which is a favorite exam detail.
Personal Views and Sharing
Any user with the Create privilege on saved views can build a personal view with modern advanced find and keep it via Save as. Personal views appear under My views in the selector. To let colleagues use one, the owner shares it with specific users or teams, granting granular access rights — Read, Write, Delete, Append, Assign, Share — and sharing itself requires the Share privilege on saved views. Shared views appear in the recipients' view selector automatically; there is no publish step, because personal views are user data rather than solution metadata.
Modern Advanced Find
The modern advanced find is now the default query experience: a filter builder plus Edit columns, with Save, Save as, view management, and FetchXML download for anyone who needs the raw query. The classic Advanced Find interface is deprecated, so when a question references editing personal views or saving filters, picture the modern experience inside the app.
Traps to carry into the exam: filters can reach related table columns through relationships (one hop is the clean, supported pattern in the view editor — for example, columns of the record a lookup points to); Quick Find search only touches find columns, never the rest of the layout; and personal views cannot be selectively included or excluded per app the way public views are — sharing is the control mechanism for personal views.
Which view controls the set of columns that are searched when a user types a name into the search box above a model-driven app grid?
A service agent built a personal view showing open cases grouped by city and wants the whole service team to use it. What should the agent do?