Watch a new user meet a model-driven app and the first friction is always the same: “why am I seeing all these records?” The answer — and the fix — is the humble view. Views decide which columns show, which rows qualify and how they sort, and they are the cheapest usability win in the whole platform: no code, no form redesign, just a better default lens on the data. In this post we take views apart: the types you inherit, the modern designer you edit them with, and where personal views fit in.
Why the grid feels wrong out of the box
Out of the box, every table ships with generic views built for nobody in particular. The columns are the vendor’s guess, the sort is alphabetical, and the result is that people export to Excel just to see their own work — which should always be read as a bug report against your views. The obvious workaround, everyone building their own ad-hoc query every morning, burns minutes daily and produces twelve private versions of the truth. The right move is deliberate system views for the shared lenses, personal views for the individual ones.
The view types you already own
In the maker portal, open Tables → Account → Views and you will find more than the grids users scroll every day:
- Public views — the ones users pick from the view selector (“Active Accounts”, “My Active Accounts”).
- Quick Find view — controls which columns the search box searches and shows. When someone says “search cannot find my record”, this view is almost always why.
- Lookup view — what people see inside a lookup field’s dropdown. Add a distinguishing column here and mis-picked lookups drop noticeably.
- Advanced Find and Associated views — the defaults for queries and related-record subgrids respectively.
The “default” badges matter: each type has exactly one default, and that is the one your users meet first.
Editing a view in the modern designer
Open a view and the designer puts everything on one screen: table columns on the left (drag or click to add), a live preview in the middle, and the view’s Name, Sort by and Filter by on the right.
Three habits pay off here. First, put the columns people scan leftmost — a grid is read like a sentence. Second, sort by the column that answers “what should I look at first?”, which is rarely the alphabet. Third, keep the column count honest: past eight or nine, you are not building a view, you are rebuilding the Excel export nobody could read either.
The filter is where a view earns its name. “Active Accounts” is literally one condition — Status is ‘Active’ — and that is the model to copy: views whose names are their filters (“My Open Cases”, “Accounts With No Owner”) never need explaining in training.
System views vs personal views
Everything above is a system view: it lives in a solution, travels between environments, and shows for everyone the moment you Save and publish. Personal views are the other half of the story — users build them in the app itself (edit filters on any grid, then save as a new view), they belong to the person who made them, and they can be shared person-to-person like any record. The governance rule I give every team: when the same personal view has been shared more than twice, it is telling you it wants to be a system view. Promote it, name it properly, and retire the private copies.
Limitations worth knowing
- Views are per-table. Columns from related tables come in through lookups (one hop) — you can show the account’s city on a contact view, but not build a three-table join. That job belongs to reports or Power BI.
- Publishing is a step, not a suggestion. A saved-but-unpublished system view change is invisible to users, and “it works for me in the designer” is the classic symptom.
- Do not delete default views. Repoint the default first; apps with no default view for a table greet users with a very unhelpful blank.
Wrapping up
Views are where a model-driven app stops being a database browser and starts being an opinion about how work should flow. Spend one honest hour with your most-used table: fix the default view’s columns, give the Quick Find view the fields people actually search, and add the one filtered view your team keeps rebuilding by hand every morning. It is the least glamorous customization in the platform, and I have never once seen it fail to earn a thank-you.
