The screen you check every morning
Saved views keep a filter combination under a name. Why nothing auto-saves, why it is not called a saved search, and what storing a filter broke.
Most people narrow their contacts list the same way most days. One tag, one status, sorted by whichever follow-up is closest to due. Setting that up is four clicks, and the four clicks are not really the cost — the cost is that they are four clicks you have to remember, and a filter you forgot to set is a list that quietly lies to you. It looks like everything, and it is not.
So: name a filter combination and get it back as a chip. That is a saved view, and it is a small feature. Most of the work in it was not storage. It was working out what changes about a filter when it stops being something you set and becomes something you keep.
What a view holds, and the one thing it deliberately does not
The search text, the tag, status and reminder filters, and the sort column with its direction.
Not the page number. A view always opens at page one — because the screen I check each morning, if it reopens on page four of a list that has changed underneath it, is not the screen you saved. It is a different set of people in the same frame.
Why it is not called a saved search
Recruiters are the people this is mostly for, and recruiters already know that phrase: LinkedIn Recruiter and LinkedIn's own people search both ship a feature by exactly that name. The familiarity was the argument against it. There, a saved search searches LinkedIn, and tells you when new people match it. Here it searches your own rolodex and tells nobody anything. Borrowing a name borrows the expectation attached to it, and this is not a feature that meets that one.
It also under-describes. A view with no search text at all — everyone with an overdue reminder, oldest first — is a perfectly good saved view and not a search in any sense.
Custom views lost for a duller reason: "custom" already means something specific here — user-defined rather than template-derived, over on campaign types — and it implies a configurable layout, columns and widths, which this does not do.
Nothing auto-saves
This is the decision most of the rest follows from. Change a filter while a view is active and the chip marks itself and offers three things: Update view, Save as new, Revert. None of them happens on its own.
A view you open every morning is infrastructure. If narrowing it once to answer a question rewrote it, the screen you rely on would be one careless afternoon away from being a different screen — and you would find that out on a morning when you were trusting it. So unsaved edits behave like any ad-hoc filter: they survive a trip into a contact's record and back, a refresh drops them, and the stored view is untouched until you say otherwise.
The same instinct put Close view directly above Delete in the manage menu, worded to keep them apart: leaving a view is not destroying one. And reordering is two menu items, move left and move right, rather than dragging — dragging would be the one write in the dashboard with no keyboard equivalent.
A view is the filter bar, not a shortcut past it
Opening a view sets the filter bar, and the bar stays live underneath it. Not disabled, not hidden. That is not a courtesy, it is where the feature's correctness comes from: a view is resolved into the same query string the bar already builds, so there is no endpoint that returns a saved view's contacts.
Resolving one on the server would have meant two implementations of the same filter semantics, drifting apart from the day the second was written — and a stored view could then return rows the live bar was unable to reproduce or edit. One query path means a view can never show you something you cannot then adjust by hand.
The one exception is the address bar. Filter state lives in a context rather than in the URL, on purpose — except that a view has its own link. A bookmark is most of what turns a saved view into a morning routine rather than a preference, and a preference is much the smaller thing.
"No view" had to become something you can see
Here is the bug, because it is the most useful thing the feature taught us.
Leaving a view for the plain list originally dropped the selection and kept the filters. The plan said that was reasonable and so did the first implementation: you are doing ad-hoc filtering now, starting from where you were. In use it was plainly wrong. Clicking Contacts in the nav produced a rail with nothing selected above a list still narrowed by the view you had just left, and nothing on the screen admitted to the filtering. Every scripted check passed, because each asserted the two halves separately and neither noticed they had started to disagree.
The fix was two-sided and the second half mattered more. Leaving a view now clears its filters along with its selection, so the nav item means what it says. And All contacts became the first chip in the rail — the cleared state made visible — lit only when no view is active and the filters are at their defaults, so it never claims to be showing everything over a narrowed list.
A state made of two fields that must agree is a state that will eventually disagree. Making the empty case of the second one visible is what stops it being silent.
What storing a filter broke
Three things, none of which the live filter bar had ever been wrong about:
- Sort direction was not something you could keep. It was recomputed from the sort column on every render — fine while direction was derived, useless the moment someone wants to store by last contacted, oldest first. There is a direction toggle beside the sort chip now, and choosing a column sets that column's natural direction once, as a starting point.
- The filter and sort vocabularies lived in two places, once in the server's checks and once in the dashboard's markup. Identical by convention, which is enough right until a stored value turns the convention into a correctness requirement. They are one shared list now, so adding a filter is a compile error in the file that has to agree rather than a value a route silently ignores.
- A view can name a tag no contact carries any more. Before this, a tag filter could only be chosen from the tags actually in use, so it was always one of the options. A stored view breaks that: the list was filtered while the dropdown fell back to its placeholder and claimed it was not. An active tag is now added to the options when it is missing. It is the clearest case of the whole class — a stored value outliving the vocabulary it was drawn from.
What a view is not
A saved view holds the filters you chose. It computes no set on your behalf and watches for nobody who newly matches one — nothing arrives, nothing is pushed. It is a named way back to a list you already know how to build: a smaller claim than this category usually makes, and the whole of what the name has to carry.
Free keeps 3, paid plans are unlimited, and editing or reordering the views you have is never limited — only creating a new one past the cap. Until there is a filter combination worth keeping, the rail renders nothing at all.