Sorting records

A sort stores a field key and ascending or descending direction on one view. It changes presentation only. Filters run first; then the sort list is applied in order; grouping places the resulting records inside buckets.

Comparison by field kind

• Number and Time tracking compare their numeric values.
• Date compares the start of a date range. An unparseable date is treated as empty for ordering.
• Created at and Updated at compare timestamps.
• Formula and Rollup server-window sorts use the field’s declared result kind: numeric, date, checkbox, or text. JSON results cannot be pushed into the ordered window.
• Checkbox compares booleans.
• Relation compares the formatted linked-record titles.
• Multi-select compares the formatted option-name list.
• Select and Status compare their displayed option text, not option order.
• Other kinds compare formatted strings with natural numeric ordering and case-insensitive collation.

Ascending therefore means smallest, earliest, or A–Z. Descending reverses the comparison. When two records compare equally under one sort, the next sort breaks the tie. If every configured sort ties, record ID provides a stable final order.

Empty values

The windowed database query deliberately places empty values last in both directions. The in-memory fallback comparator currently reverses its empty comparison for a descending sort, which can put empties first on a client-only record set. That inconsistency is a current limitation; do not use descending empty placement as a workflow rule.

Manual order

With no sort, the view keeps the record order supplied by its layout, including the manual order manifests used by Table, Board, Calendar, and Timeline. Adding a sort takes precedence over that order. Remove all sorts to make the layout’s manual order effective again.

Group order is separate. Sorts order records inside a group; the group’s manual, ascending, or descending setting orders the group buckets themselves. See Grouping records.