Every database view type
Table, list, board, gallery, calendar, timeline, and chart views, including their required fields and saved settings.
A database owns records and fields. A view is a saved presentation of those same records with its own kind, filters, sorts, group, field visibility, manual order, and display settings. Changing a view does not copy or move its records.
Canonical contract values:
tablelistboardkanbangallerycalendartimelineganttchart
kanban and gantt are readable legacy aliases. kanban renders through the
Board implementation and gantt through Timeline. New choices and documentation
use board and timeline, so the aliases do not have separate entries below.
Shared settings
Every view can save filters, an ordered list of sorts, one group configuration, visible field keys, conditional formatting, and whether the record title is shown. A view may be shared or personal. Standalone views have their own sidebar item but still point to a view row whose data source is exactly one database.
Changing layout preserves shared settings where they remain meaningful. A layout-specific setting, such as a Timeline end date or Chart axis, stays in the view manifest but other layouts ignore it.
Layouts
Table table
Renders records as rows and fields as columns. Its manifest stores the visible column allowlist and order, per-column widths, pinned columns, manual record order, title label/icon, and title visibility. It is the layout for editing many values in place and for adding or rearranging fields from headers.
Grouping draws collapsible row sections. Filters run before the rows are grouped and sorts order records within each group. Empty values sort after non-empty values.
List list
Renders one compact row per record, with the title and the fields enabled in the view’s Properties setting. It supports the same filtering, sorting, and grouping engine as Table but does not expose a grid of editable columns. Use it when the record title is the main thing people scan.
Board board
Renders cards in columns. Its group field must be Select or Status; each option becomes a column and dragging a card writes that option back to the record. Status columns keep their configured manual option order. Empty columns can be kept visible so they remain valid drop targets.
Board also uses the view’s visible-property list to decide which fields appear on each card. It cannot make columns from arbitrary text, relation, or date values even though those kinds can be grouped in non-board layouts.
Gallery gallery
Renders a larger card for every record, using the record title and the properties enabled for the view. It supports shared filters, sorts, and grouped sections. The current view contract has no dedicated gallery-cover field or card-size setting, so do not rely on either as saved configuration.
Calendar calendar
Places each record on a calendar using dateFieldKey; when that setting is
absent it uses the first Date field. The database therefore needs a Date field
to place records. Dragging or resizing calendar events updates that date value.
The saved display mode is month, week, day, or agenda. The view can hide weekends, choose which weekday starts the week, and configure weekend days. Filters and sorts still run before calendar events are built. A record with no value in the chosen date field is not placed on a day.
Timeline timeline
Draws records as bars from dateFieldKey to an optional endDateFieldKey.
Without an end field, each record becomes a single-day bar. The axis scale can
be day, week, month, quarter, or year, and the view persists its zoom and manual
row order.
Optional channels bind real fields to progress (Number or Checkbox), milestone (Checkbox), baseline start/end (Date), and assignees (User). Display switches show or hide owner, tags, days, dependency lines, and critical-path highlighting. The timeline renderer supports dependencies, but those links are separate from the start and end date fields.
Chart chart
Aggregates the records that survive the view’s filters. Chart types are vertical
column, horizontal bar, line, donut (pie in the manifest), and a single
number. An X-axis field creates categories; the Y axis either counts records or
uses a numeric field, and an optional second field segments a series.
Chart settings include manual/ascending/descending category order, omitting zero values, automatic or fixed range, reference lines, colour, labels, smooth line, stacking, title, and small through extra-large height. Stacking only applies to bar and column charts. A chart is a view over current records, not a stored snapshot, and it does not write values back.
Per-view and per-database changes
Filters, sorts, grouping, field visibility, layout, and layout-specific settings belong to one view. Field definitions, option lists, record values, formulas, and relations belong to the database and affect every view. Hiding a property in one view does not delete it; deleting a field does.
Next: Filtering records, Sorting records, and Grouping records.