Almanac
Microsoft/dataversePower Platform

Consultant KB for Microsoft Dataverse, the data layer under Dynamics 365 and the Power Platform: data model, security model, business logic, APIs and integration, search and queries, analytics and Fabric, ALM and solutions, administration, governance and compliance, and Dataverse as an agent data platform, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Dataverse release plans, docs repo and product blog, plus the author's own consultant notes.

dataverse/05-search-and-queries/feature-views-and-filtering.md
feature-views-and-filtering.mdv1 · history
CurrentApplies to MakerUpdated last monthSource Microsoft Learn ↗

What it does

A view defines which columns show in a list, in what order, at what width, sorted how, and filtered by what. Model-driven apps use them for grids, subgrids, lookups and chart data sources. Underneath, a view is a saved FetchXML query on the savedquery (system and public) or userquery (personal) table.

Key facts

  • Three types. Personal views belong to one user and are shared explicitly. System views are the special-purpose ones the platform depends on. Public views are the general-purpose ones users pick from the view selector.
  • The four system view types are Quick Find, Advanced Find, Associated and Lookup. They don't appear in the view selector, can't be used in subgrids or dashboards, and can't be deleted or deactivated.
  • Quick Find does double duty: it's the default search view and it defines which columns are searched by quick find, lookup search, and Dataverse search.
  • Advanced Find view defines the default columns used when someone creates a new public or personal view without picking a template.
  • Every new custom table gets Active, Inactive, Quick Find Active, Advanced Find, Associated and Lookup views out of the box.
  • You can delete custom public views you created in an unmanaged solution. You can't delete system-defined public views, and public views that arrived in a managed solution should only go by uninstalling or updating that solution.
  • Personal views need at least User-level access on the Saved View table. You can dial that up or down per action in the security role.
  • System views are cached for performance, which is why plug-ins on the savedquery table aren't supported.
  • The Power Apps grid control is the one to standardise on. The read-only grid, editable grid and legacy read-only grid are all deprecated.

When to use / skip

Public views are for shapes the whole business shares — Active Cases, My Open Opportunities, the things that go on a dashboard. Personal views are the pressure valve that stops users demanding forty public views nobody else wants. The mistake I see most is treating public views as free: every one you ship is a solution component, appears in everyone's selector, and someone has to maintain its filter when the process changes. Ten well-named public views beat forty that users scroll past. And if a view exists purely so one manager can see one thing, that's a personal view they can build themselves.

Configuration decisions

  • Which views are public and which stay personal, driven by whether more than one role genuinely needs the shape.
  • Which columns go into Quick Find's Find columns, because that decision reaches straight into search behaviour and into the Dataverse search index budget.
  • Default sort order per view, and whether it's on a column that can actually use an index.
  • Whether the grid is read-only or editable, using the Power Apps grid control rather than any of the deprecated ones.
  • Which public views each app exposes, decided in the app designer rather than by shipping everything.

Gotchas

  • Editing the Quick Find view to fix a search problem changes the Dataverse search index too. Those are one setting wearing two hats and people change it thinking it's local.
  • Sorting a view by a choice column means sorting by localised label, which needs a join and extra compute. Same for sorting by a column on a related table. Both make a grid noticeably slower with no visible cause.
  • A view filtered on a formula or calculated column forces the platform to compute that value for every candidate row before filtering. It'll work in dev with 500 records and time out in production.
  • Deleting a managed public view by hand rather than by updating the solution leaves you in a state you can't cleanly recover.
  • Users can reorder and refilter a grid at runtime, so "the view is wrong" reports are often "the user changed the grid" reports.

Consultant notes

  • Do a view cull before go-live. Every environment I've inherited has three views nobody has opened in a year and one that scans the whole table.
  • Make the client own the naming convention. "Active Accounts – Northern Region" ages better than "Accounts 2".
  • Warn against building reporting into views. A view is a list, not a report — the moment someone wants a total by month, that's a chart or Power BI, not a grid with 40 columns.
  • If they're still on the legacy read-only or editable grid controls, put the migration on the roadmap now rather than when the deprecation date bites.

Revisit when the Power Apps grid control finishes replacing the older grids, or if managing access to system views leaves preview.

Was this accurate?
Related
Dataverse search05-search-and-queriesPrivacy and data subject requests09-governance-and-complianceTables and columns01-data-modelMatrix data access structure (modernised business units)02-security-modelVirtual tables01-data-modelVirtual table data providers04-apis-and-integration