---
title: Saved Views
slug: saved-views
kind: pattern
summary: A named, reusable combination of filters, sort and columns — so the list someone rebuilds every morning becomes one click, and a team can agree on what "the overdue list" means.
problem: >-
  People rebuild the same three or four filter combinations every day, from
  memory. Everyone's version is slightly different, so two colleagues discussing
  "the overdue list" are looking at different rows and do not know it.
family: [find, coordinate]
data_shape: [collection]
principles: [friction, consistency, orientation]
interaction: [filtering, navigation]
density: low
complexity: medium
status: stable
visibility: public
use_when:
  - The same filter combinations get rebuilt repeatedly by the same people.
  - A team needs to agree on what a named slice of the data means.
  - Different roles care about genuinely different slices of one collection.
avoid_when:
  - There are only two or three useful slices ever. Make those tabs — they are more discoverable and need no management.
  - Every query is genuinely one-off; saving them creates clutter nobody prunes.
  - The filter bar itself is not in place yet. Saved views are a layer on top of filters, not a replacement.
alternatives:
  - slug: filter-bar
    when: People need to narrow ad hoc and the combinations do not repeat.
  - slug: global-search
    when: They know the specific record, not a description of a set.
ask_leo: |
  Let people save a filtered view of this collection under a name.

  - A saved view captures the filters, the sort order, and the visible columns —
    everything that makes the list look the way it does.
  - Show saved views as a row of named tabs above the list, with the active one
    marked. Opening one applies its whole state.
  - Keep the underlying filter bar visible and editable. When someone changes a
    filter while a view is open, show that the view has unsaved changes and
    offer "update this view" and "save as new" as separate actions.
  - Support both personal views and shared team views, and label which is which.
    A shared view is a team agreement about what a name means, so changing it
    affects other people — say so before saving.
  - Give each view a URL so it can be linked to directly.
  - Let people reorder and remove their own views. A list of views nobody prunes
    becomes the same problem as no views at all.
related:
  - title: Filter Bar
    url: /patterns/filter-bar
    summary: The layer underneath — saved views are named filter states.
---

## Anatomy

```
┌──────────────────────────────────────────────────────────────┐
│  All   ● My overdue   Dana's chase list*   Team: unassigned   + │
│                                            ↑ shared   ↑ edited │
├──────────────────────────────────────────────────────────────┤
│ Status ▾  Owner ▾           ● Overdue ✕  ● Owner: Dana ✕      │
└──────────────────────────────────────────────────────────────┘
```

Three properties do the work:

1. **It captures the whole view**, not only the filters — sort and columns too.
   A view that restores the rows but not the ordering has not restored the view.
2. **The filter bar stays visible and live.** A saved view is a starting point,
   not a lock. Editing from a view is the most common thing people do.
3. **Personal and shared are distinguishable.** They are different objects
   socially: one is a shortcut, the other is an agreement.

## Why it works

It converts a repeated act of memory into a click, which is the highest-value
friction removal available on a list — because it is paid every single day by
the same people.

The team effect is the larger one, and it is easy to miss. A shared view named
"Needs chasing" is a **definition**. Before it exists, six people have six
private definitions and their numbers never quite agree; afterwards there is one
list, and disagreements about it become explicit rather than invisible.

That is also why editing a shared view deserves a warning. Quietly changing what
a name means is more disruptive than deleting it, because everyone keeps using
the name and the meaning has moved.

## Getting it wrong

- **Saving only filters.** The sort was part of what made it useful.
- **No unsaved-changes state.** People edit a view, expect it to stick, and lose
  the change — or worse, expect it *not* to stick and overwrite a shared one.
- **No pruning.** Twenty stale views is a worse menu than none, and nobody
  deletes other people's.
- **Views instead of good defaults.** If everyone's first act is to switch away
  from the default view, fix the default.
- **Building views before filters work.** The layer underneath has to be solid,
  or every view inherits the same gaps.

## Exemplars

**Linear's views** show the personal-versus-shared distinction handled
explicitly, and the "unsaved changes" state done well: you can always tell
whether you are looking at the view or at your own edit of it.

**Airtable's saved views** go furthest — each view carries its own fields, sort,
grouping and even type of display — and demonstrate the cost too: a base with
forty views needs someone to curate them.

**Gmail's search-backed labels** are the same idea with a different surface, and
make the point that a saved view is really a named query.

The extractable rule: **a shared saved view is a definition, not a shortcut.**
Treat renaming and editing it as a change to a shared agreement, because that is
what people will experience.