Filter, group, and summarize a table

Sometimes you don’t need an automation, you need an answer: how many cars were red last week? what’s the average ticket value by status? Building a flow for a one-off breakdown is overkill. Views answer this directly on the table itself — filter, group, and summarize your rows, save the result as a tab, and reuse it on a dashboard.

This guide covers building a view by hand, describing one in plain English instead, and what a view is (and isn’t) good for.

What a view is

A view is a saved way of looking at one Custom Table: a set of filters, an optional group-by, and optional summary numbers. Every table already has one view for free — All rows, the plain grid with nothing filtered or grouped. Anything else you save (Cars by color, Open tickets this week) shows up as an extra tab next to it.

Views are addressed as table.view — the bare table name always means “all rows”; a saved view adds its own slug after a dot. You don’t need to think about this address directly, it’s just the shape a link like /tables/cars?tab=cars_by_color takes.

Two shapes come out of the same view:

• A row view (no grouping) — the filtered rows themselves, with an optional summary footer under the last row (a count, sum, or average per column, computed over every matching row, not just what’s on screen).
• A grouped view (grouping turned on) — one row per group instead of one row per record, with a metric column per group (count, sum, average, minimum, maximum, or distinct count) and a Total row underneath that’s a real aggregate over the whole matching set, not a sum of the visible groups.

Both run as one SQL query over your entire table — filtering and grouping are never limited to whatever page of rows happens to be on screen. A “last 24 hours” filter or a group-by-color count is exact even on a table with tens of thousands of rows.

Building a view

Open a table and click + New view next to the saved-view tabs. You get three controls, Notion/Airtable style:

• Filter — pick a column, an operator, and a value. Add as many as you like; they’re all combined with AND (there’s no OR or nested grouping — see What views don’t do below). The operators on offer depend on the column’s type: text columns get is / is not / contains; select columns add is any of / is none of; numbers get comparisons and between; dates add before / after / in the last N hours-days-weeks.
• Group by — pick a column to group on. Group by a date or datetime column and a bucket option appears — more on that below.
• Summarize — pick one or more metrics (count, sum, average, minimum, maximum, distinct count) once you’ve set a group-by.

Whatever you build, an always-on plain-English sentence above the results tells you exactly what the view shows — for example:

Cars where Color is not Unknown and Detected at in the last 24 hours, grouped by Color (count).

This line updates live as you edit the filter/group/summarize controls, and it’s shown to anyone looking at the view, whether they built it or not — so nobody has to reverse-engineer a saved view’s filters from the results.

Name the view and save it, and it appears as a new tab. Anyone with access to the table can switch between tabs; each one keeps its own filters.

Describe it in plain English instead

If you’d rather not click through the filter builder, type what you want into the Describe what you want box in the view editor — “cars by color in the last week, excluding unknown” — and Routario drafts the filter, group-by, and metrics for you. The draft lands in the same editor as an ordinary set of filter chips: nothing is saved until you review it and hit Save. If the request doesn’t parse into something the compiler can run, you get an empty draft to build on by hand instead — the AI step never silently guesses at something it isn’t sure about.

Grouping by time: two different questions

Grouping a date or datetime column offers two families of bucket, because “by day” and “by day of week” answer different questions:

• Sequential buckets — hour, day, week, month — plot a timeline. Each bucket is one specific point in time (this Tuesday, not Tuesdays in general), so a chart of these only has bars for periods where something actually happened.
• Cyclic buckets — hour of day, day of week, month of year — collapse the whole timeline into a repeating cycle. “Traffic by hour of day” answers “what does a typical day look like”, not “what happened on any specific day.” Because the question is about the shape of the cycle, cyclic buckets always show every slot in the cycle — all 24 hours, all 7 weekdays, all 12 months — even the ones with zero matching rows, so the shape reads correctly instead of looking like missing data.

Per-column display

Each saved view can also control, per column, whether it’s shown at all and how its value is displayed — independent of the raw stored value:

• Hide columns you don’t need cluttering this particular view.
• Dates and times default to your workspace’s timezone, or you can switch a column to UTC, relative (“3 min ago”), date-only, or time-only.
• Numbers default to their raw value, or you can render a column as a percent, a fixed 2-decimal number, or a rounded integer.

These are per-view, per-column settings — the same underlying table can show a date as “3 min ago” on one saved view and as a plain UTC timestamp on another.

Using a view on a dashboard

A dashboard chart tile can point at a saved view instead of a raw table. Do this and the tile renders exactly the aggregate the view computes — the same grouped counts you’d see in the grid, as a bar, line, or pie instead of a table. Building the breakdown once as a view and then charting it means the grid and the dashboard can never quietly disagree about what “cars by color” means.

Both the grid and any dashboard tile built on a view update automatically when the underlying rows change — add, edit, or delete a row and the numbers refresh without anyone reloading the page.

Worked example

A yard camera logs every vehicle it detects into a cars table — a plate column, a color select column, and a detected_at datetime column. You want a running answer to “how many of each color came through today, ignoring anything the camera couldn’t identify”:

1. Open the cars table and click + New view.
2. Add two filters: Color is not Unknown, and Detected at in the last 24 hours.
3. Set Group by to Color, with no bucket (it’s a select column, not a date).
4. Add a Count metric.
5. Name it Cars by color and save.

The result: a Cars by color tab next to All rows, showing one row per color with its count and a real total underneath — recomputed instantly as new detections land, and reusable as-is on a dashboard tile if you want it charted.

What views don’t do

Views are deliberately a lightweight, single-table layer — not a query builder. They don’t do:

• Joins. A view only ever reads one table.
• OR logic or nested filter groups. Every filter you add is combined with AND; there’s no “this OR that.”
• Derived or computed columns. A view groups and summarizes columns that already exist — it doesn’t calculate a new one.
• Cross-table anything. No lookups into other tables, no rollups from a related table.

If what you need crosses one of these lines, that’s a job for a flow: pull from wherever the data lives, combine it however you need, and write the result into a table — which you can then filter, group, and summarize with a view like any other.

Where to go next

• Working with data: tables and imports — creating tables and getting rows into them in the first place.
• Building an automation — when a view isn’t enough and you need a flow to combine, transform, or cross reference data first.
• Find records reference — reading rows from a table inside a flow, as distinct from a view.