Same table, infinite perspectives. Build saved views that filter, sort, and group your data — showing exactly what each person needs to see.
A view is a configured lens on a table. It does not copy or move data — it displays the same rows and columns through a set of filter, sort, group, and visibility rules you have configured. Change a cell value in any view and the change appears in every other view of that table instantly, because they all read from a single source of truth.
Multiple views let you serve multiple audiences without duplicating your data. Your "All Tasks" table might power a "My Open Tasks" view for individual contributors, a "Team Kanban" view for stand-ups, and a "Completed This Month" report for management — all simultaneously live, all zero maintenance.
Each view remembers its own configuration independently. Filter settings, sort order, group-by column, and column visibility are all stored per view. Changing the sort in one view does not disturb any other view.
A temporary configuration you set up while working — sort by due date, scan what is urgent, then move on. Not saved as a named view; resets next session.
A named, persistent configuration that lives in the sidebar. Anyone with access reopens it and sees the exact same filtered, sorted arrangement every time.
You can create a new saved view in any of three ways. All three result in a named, independently configurable view of the same underlying table.
Open a table, click the view switcher in the top-left corner (shows "Default view" or a table icon), then click + Add view. Name it, choose a type, and configure.
Type /view anywhere on a canvas page. Coda opens the slash command picker where you select a table and an existing or new view to embed.
Use /view on a different page — like a dashboard — to embed and simultaneously create a new view of any table, from any page in the doc.
A filter rule has three parts: a column to evaluate, an operator that defines the relationship, and a value to compare against. You can stack multiple rules with AND (all conditions must be true) or OR (any one condition must be true). Rows that fail the filter are hidden — not deleted — and reappear the moment the filter changes or they gain a matching value.
| Operator | Works on | Example |
|---|---|---|
is |
Any type | Status is "In Progress" |
is not |
Any type | Status is not "Done" |
contains |
Text, Select List | Tags contains "Design" |
does not contain |
Text, Select List | Tags does not contain "Archived" |
is empty |
Any type | Owner is empty |
is not empty |
Any type | Due Date is not empty |
is before |
Date | Due Date is before today |
is after |
Date | Created At is after Jan 1 2025 |
is between |
Date | Due Date is between Today and next Friday |
When you stack two filter rules, Coda asks whether they connect with AND or OR. AND narrows the result; OR broadens it.
Owner is "Alice" AND Status is "In Progress"
Shows only Alice's in-progress tasks. A task owned by Alice that is "Done" won't appear. A task by Bob that is "In Progress" won't either.
Status is "Blocked" OR Priority is "High"
Shows anything that is blocked or high priority — or both. Good for an "attention required" view that catches problems from multiple angles at once.
Sorting reorders displayed rows without touching the underlying data. You can set a primary sort and one or more secondary sorts — Coda resolves ties in the primary sort using the secondary sort. For dates, ascending = oldest first; descending = newest first. For text, ascending = A→Z.
Grouping reorganises rows into collapsible stacks based on a select or person column value. Every row whose "Status" column says "In Progress" gets bundled under an "In Progress" header. Coda shows the row count next to each group header automatically, and you can collapse any group to hide its rows and scan just the bucket names.
| Task | Due Date | Priority |
|---|---|---|
| Fix login bug | Apr 8 | High |
| Review design comps | Apr 10 | Medium |
| Update changelog | Apr 14 | Medium |
| Write release notes | Apr 18 | Low |
Every view has its own column visibility settings. Hiding a column in a view removes it from the display — but the data is still there. Other views that show the column still display it. Formulas that reference the column still work. Automations that read or write it still fire. The column just is not rendered as a grid column in this particular view.
This is extremely useful for building role-specific views. A "Client Summary" view might show only Task Name, Status, and Due Date, hiding internal columns like Notes, Effort Estimate, and Cost Code. The data team still sees all columns in their view. Neither side has to compromise on layout.
The real power of views becomes clear when you start building purpose-specific lenses for daily workflows. Here are three recipes to implement immediately in any task or project table.
Filter: Owner is @Me AND Status is not Done Sort: Due Date ascending
The daily driver view. Shows only your uncompleted tasks, closest deadline first. Lock the Owner filter so it cannot be accidentally removed.
Filter: Due Date is between Today and DateAdd(Today, 7, "days") Sort: Due Date ascending
Everything due in the next 7 days across the whole team. Add a group by Owner to see each person's weekly load at a glance.
View type: Board Group by: Status (To Do / In Progress / Done)
Drag cards between status columns to update values. Board view is the same data as table view — just displayed as swim-lane cards instead of rows.