Users spend more time in tables than in any other viewer, and that's not changing soon. Kanban boards are wonderful for pipelines. Calendars are unbeatable for time-based work. But when the question is "show me a lot of records, in rows, so I can scan, sort, and filter them with minimum friction," the answer is always a table. That's where precision work happens — reconciliation, reporting, bulk updates, cross-referencing. Getting the table right has been one of the quiet focuses of the platform for the last several years, and it shows.
The basics behave exactly the way users expect them to. Click a header to sort, click again to reverse, a third time to clear. Pagination is tunable per view and the page-size choice is remembered per user — a power user who wants two hundred rows at a time keeps getting two hundred, while a less technical colleague on a slower connection keeps their smaller page. Column visibility can be adjusted on the fly, and the choice persists within the view, so columns you hide once stay hidden the next time you come back. A view can also rename columns for display without renaming the underlying property, which is a small feature that saves a surprising amount of cognitive load when a technical property name doesn't quite match the term a business user would use.
Small rendering details turn a generic table into one that's actually comfortable to read. Per-property colors let enumeration values appear as color-coded pills, so a quick eye sweep is enough to pick out the rows that matter. Image properties render inline with a configurable thumbnail width per property, so a table of products can show at-a-glance pictures without eating the whole column. Money values carry their currency; dates respect the user's locale; references link through to their target record. Density, when you want it, is high; readability, even at density, stays good.
The area we've spent the most engineering attention on is large result sets. Selecting a few rows is easy. Selecting a few thousand rows, across several pages, surviving a filter change in the middle, and then performing a bulk action on all of them — that's harder. Our table handles it. Selection persists across pagination; it survives re-sorting; it can span pages of results a user hasn't even scrolled through yet. When the selection grows beyond what fits in a URL, the platform transparently switches to a form submission so operations like delete selected, update selected, or export selected keep working without truncation. From the user's perspective, nothing changes; the mechanics behind it simply scale.
Grouping and inline calculations add a layer of analytical capability on top of the flat list. Multi-level grouping collapses a long table into something browsable — first by region, then by salesperson, then by status. Per-group subtotals and a grand total appear in their own row, with sum, count, average, and other standard aggregations available. For most reporting needs this is enough to skip a detour through a spreadsheet. The grouping-and-calculations article covers the details.
The default sort, default filters, and default columns are all inherited from the view the user opened, but every user can override them locally for the session. That preserves the curated design the view's author intended while respecting the reality that individual users sometimes need to look at the same data a slightly different way in the middle of a task. Resetting returns the table to the view's defaults.
A handful of small touches round the experience out. Keyboard navigation for row-to-row movement, quick filter boxes above the columns, sticky headers when scrolling long lists, column-width adjustment that remembers your choice. None of these is a headline feature, but together they're the difference between a table you tolerate and a table you don't have to think about.
When users need to take the data offline — into a meeting, into a report, into a colleague's hands — the spreadsheet exports respect the table exactly as it's been configured. Columns, sort, and filters carry through; the file they receive looks like the screen they were just working with. That continuity is deliberate. The table is a working surface, and the export is how that work leaves the building.
For everything the table can't quite do — deep pivoting, unusual layouts, custom cell rendering — the view layouts and canvas articles take over. But the common ninety percent of tabular data work is exactly what the table is built for, and it gets better with each iteration.