The same set of records serves very different people. The sales team wants to see deals as a kanban moving across pipeline stages. The accountant wants a dense table of overdue invoices, sorted by age. The support agent wants a calendar of scheduled callbacks this week. A CEO wants a card-based summary for a monthly review. Forcing all of them through one list view is how applications end up with twenty-column tables that nobody actually reads. Views are our answer: a saved way of looking at a set of records, composed from pieces each role can mix and match for themselves.
A view is, conceptually, three things stacked together. First, a query — the underlying data, shaped by conditions, parameters, and sort order. Second, a viewer — a renderer that takes that data and presents it in a particular shape. The same query can be rendered as a table, a list, a set of cards, a kanban board, a calendar, or a custom canvas layout, and switching between them is the click of a button. Third, a view configuration — the specific columns to show, the renamings, the default grouping, the preset filters. Separating these three layers is what lets a single record set serve several roles without any of them feeling like they're using the wrong tool.
Columns and visibility are configured per view. You pick which properties matter, in which order, with optional renaming for readability. A view can define a default sort and a default grouping, which persist across sessions so that when a user returns to their accounts-receivable view at eight in the morning, it's already organized the way they left it. Default filter values let a view open with an opinionated starting point — open tickets assigned to me rather than all tickets in history.
A type typically carries several views, and the platform treats them as first-class citizens. A default view per type is the one a user lands on when they haven't chosen otherwise. Each user can then bookmark their own preferred query within that view, which is a small but genuinely nice touch: the team lead can set a sensible default for everyone, and individuals can quietly personalize it for how they actually work.
Per-role view availability is where multi-persona implementations get clean. The kanban is visible to salespeople; the table is visible to accountants; a simplified card view is visible to read-only observers. Each role sees exactly the set of views that makes sense for their job, and nobody has to scroll past seven irrelevant options to find the one they use every day. The views are still backed by the same data and the same type definition, so there's no divergence to maintain.
A small but important ergonomic detail: views have shareable URLs that carry the full context — the query parameters, the filters a user has applied, the sort they chose, the column visibility they adjusted. Paste that URL into a chat and a colleague opens the application to exactly what you were looking at, permissions permitting. Meetings end with a list of links instead of a list of screenshots, and that small change compounds quickly in a busy team.
Views also compose with the rest of the platform in predictable ways. The REST API exposes them; automations can run against a saved query; spreadsheet exports follow the view's columns and sort; widgets on the homepage can pull a view directly. Defining a view once means defining it for every surface where that data shows up.
Each viewer has its own article worth reading: the table view for dense data work, the kanban for workflow-style data, the calendar for anything time-based. The view layouts piece covers the more sophisticated case where a single screen combines several viewers together — a list on the left, a detail panel on the right, a card grid above. And the query builder article is the natural companion, since getting the query right is usually what makes a view feel sharp rather than busy.