Views
A view is a saved configuration of how you look at a table. It stores which fields are visible, how records are filtered and sorted, column widths, grouping, and (for some view types) layout-specific settings. Switching between views never changes the underlying records — it only changes what you see.
What a view is
Every table starts with a default view. You can add as many named views as you need: one for your full dataset, one filtered to this week's open Tasks, one grouped by status — all reading from the same records.
View configuration is stored in viewSettings on the view row:
columnVisibility— which fields are shown or hiddencolumnOrder— the display order of fieldscolumnWidths— per-column pixel widthsfilters— an array of filter rulessorts— an array of sort rulesgroupBy— the field used to group records
Changes to view settings (reordering columns, adjusting a filter) are saved immediately. They are per-view — adjusting one view has no effect on another.
View types
Grid
The default view. Records appear as rows and fields as columns in a virtualised grid. Rows are selectable, cells are inline-editable, and the grid supports range selection with copy/paste (TSV format).
Row height has four options: short (26 px), medium (34 px), tall (52 px), and extra-tall (80 px). The first data column is sticky-frozen alongside the row-marker column.
An optional footer row can show a sum or average for any NUMBER field that has an aggregate configured.
Board (Kanban)
Groups records into swimlane columns driven by a SELECT field. Each option in the select becomes a column; records appear as cards inside their respective column. Dragging a card between columns updates the underlying SELECT value.
Board view requires a SELECT field to group on. You pick the grouping field when creating or configuring the view.
Gallery
Displays records as cards in a grid layout — useful when records have an image file field or when you want a more visual overview than the grid provides.
Calendar
Displays records on a calendar grid keyed to a DATETIME field. Useful for Tasks with due dates, events, or any time-based dataset.
Gallery and Calendar views are available for all tables. Board view requires at least one SELECT field.
Filters and sorts
Filters
Filters narrow which records the view shows. Each filter rule has three parts: the field, the operator, and a value.
Operators vary by field type:
| Field type | Available operators |
|---|---|
| TEXT, LONGTEXT | contains, equals, does not equal, starts with, ends with, is empty, is not empty |
| EMAIL, PHONE, URL | contains, equals, does not equal, is empty, is not empty |
| NUMBER | equals, does not equal, greater than, greater than or equal, less than, less than or equal, between, is empty, is not empty |
| SERIAL | equals, does not equal, contains, starts with, ends with, is empty, is not empty |
| BOOLEAN | is true, is false, is empty, is not empty |
| DATETIME | equals, does not equal, is after, is on or after, is before, is on or before, between, is empty, is not empty |
| SELECT | equals, does not equal, is any of, is none of, is empty, is not empty |
| MULTISELECT | is any of, is none of, is empty, is not empty |
| FILE | is empty, is not empty, MIME type is, MIME type is not |
| REFERENCE | is empty, is not empty, contains, is, is not |
| FORMULA | Inherits operators from the formula's display_as type |
| AI | contains, equals, is empty, is not empty |
Multiple filters combine with AND logic — a record must pass all active filter rules to appear in the view.
SERIAL's string-style operators (contains, starts with, ends with) are intentional: auto-increment IDs are often searched as substrings (e.g., finding all records whose ID contains "42"), so SERIAL exposes the same string operators as TEXT rather than the range operators of NUMBER.
Sorts
Sorts order the records in a view. Each sort rule names a field and a direction (ascending or descending). The data model supports multi-field sort: you can stack multiple sort rules, and records are ordered by the first rule, then by the second for ties, and so on.
The grid currently exposes single-column sort via the column header. Multi-field sort is supported by the underlying data model and will have a dedicated UI.
Visible fields and field order
Show and hide fields
The Fields menu in the toolbar lists every field on the table. Toggle a field's visibility to show or hide it in the current view. Hidden fields still store data and still evaluate (for FORMULA and AI fields) — they're invisible in this view only.
Hidden fields don't affect other views. If you want a "clean" view with fewer columns, hide fields there without removing them from the data model.
Field order and column widths
Drag a column header to reorder columns within the view. Drag the right edge of a column header to resize it. Both changes are saved per-view in viewSettings.columnOrder and viewSettings.columnWidths.
The underlying field order on the table (used in the record dialog and as the default for new views) is separate from any individual view's column order.
Grouping
Grouping splits the record list into sections, one per distinct value of the group-by field. You can group by any one field.
SELECT fields are the most natural grouping target — each option becomes a named group, with the option's color pill shown as the section header. Other field types (TEXT, NUMBER, DATETIME) group by their exact stored value.
Board view is a specialised form of grouping: it requires a SELECT field and renders each group as a swimlane column rather than a collapsible section.
Sharing a view
Today, table access is governed by workspace membership and table-level permissions — all workspace editors can see all views on a table.
Per-view share links are coming soon. Today, table access is governed by workspace membership and table-level permissions.