Google Sheets slicers vs filter views: when to use each

Open a shared operations sheet on a busy morning and two things happen. One teammate clicks the filter funnel to look at their region, and everyone else’s view collapses with them. Someone else adds a slicer to the pivot on the summary tab, and the raw data below still shows every row. Slicers and filter views look like the same tool from a distance — both hide rows, both live in the Data menu — but they solve different problems and step on each other in surprising ways.

The one-line difference that decides which to use

A slicer is a floating control that filters a specific pivot table, chart, or table without touching the underlying rows. A filter view is a named, personal saved filter over the whole tab that hides rows only in your session. Slicers are for output — the summary that other people look at. Filter views are for input — the raw data you and your teammates edit.

The confusion comes from a third feature, the standard filter (the funnel icon in the toolbar), which sits between them. A standard filter also hides rows across the whole tab, but unlike a filter view it applies to everyone viewing the sheet at the same time. That is the setting that clobbers your teammates.

When slicers are the right tool

Slicers earn their place on summary tabs. Put a pivot table next to two or three slicers labelled Region, Product, and Quarter, and readers filter the view by clicking chips instead of learning your filter menu. Because the slicer only rewrites what its bound pivot table renders, the raw data on other tabs stays intact and the columns other formulas depend on stay populated.

The behavior most people expect from slicers only shows up once you commit to that pivot-first pattern. A single slicer can drive multiple pivots and charts on the same tab as long as they all read the same source range, so a dashboard with three linked charts filters as one unit when you click a slicer chip. That is what makes them dashboard-friendly.

• ✓ The tab shows a pivot table, chart, or summary — not the raw rows
• ✓ Readers should filter with one click, not by opening a menu
• ✓ The default filter state matters to viewers (set it with Set current filters as default)
• ✓ Multiple charts on the tab all read the same source range

Set the default state once and everyone opens the tab pre-filtered. Right-click the slicer, choose Set current filters as default, and any collaborator who opens the sheet later sees your baseline instead of an empty selection. It is the single setting that turns a slicer from a demo widget into a real dashboard control.

The slicer trap: formulas ignore it

Slicers rewrite what a pivot table shows. They do not rewrite what a formula reads. A =SUM(Data!C2:C10000) next to the slicer keeps summing the entire column no matter which chips are selected, because the slicer never touches the underlying range. Google’s own docs are explicit: slicers “don’t apply to formulas in a sheet that use the same data set” (Google Sheets Help). If a KPI card next to a slicer needs to react to the selection, that card has to be a pivot table cell, not a formula reading the raw data.

When filter views win

Filter views exist for the opposite job: a shared operational tab where every teammate needs a private slice. Support queues, sales pipelines, editorial calendars, roster sheets — the same rows, viewed twelve different ways. Each teammate creates their view once, and the funnel selections stay saved under their name without ever hiding rows for anyone else. If you have used the FILTER function to build a per-user tab, filter views are the interactive equivalent — no formula, no extra tab.

The feature most people never notice is that every filter view has its own URL. Open the view and the browser address bar picks up a &fvid=… parameter. Hand that link to a teammate and they land in your view directly, not on the default sheet. That is how you build a “my open tickets” bookmark without duplicating the tab.

View-only collaborators can still create their own filter views — Google marks them temporary and they disappear when the tab is closed, but during the session the person can slice the data without editing anything. That distinction matters for read-only stakeholders who otherwise ask you for a filtered export.

Gotchas nobody documents

Both features carry quiet limits that only bite once you scale them. Sorting inside a filter view rewrites the underlying row order for everyone unless you use Sort range → Advanced sort instead of the header dropdowns; the small “Sort A → Z” shortcut sitting in the filter menu is the shared kind. The behavior is intentional, but it burns anyone who thinks the filter view is a fully private sandbox.

Protected ranges also interact unexpectedly. A protection that allows only the owner to edit lets everyone else read but blocks them from creating a filter view on the sheet — Google treats “creating a saved view” as a write on the sheet’s metadata. Slicers behave the reverse way: a viewer can toggle a slicer on a protected tab, because the slicer just changes their local rendering.

The mobile row is the one that ships broken. The Sheets mobile app renders slicer chips as static values and refuses to create new filter views. If your team looks at the sheet from phones, a slicer that starts filtered to “APAC” via Set current filters as default is the only interaction they get. Design the default state assuming half your audience is on a phone.

A shared operations sheet, done right

The reason this comparison matters is that most real sheets need both. Put the raw ticket log on one tab with three or four filter views for the roles that live in it — one per teammate, or one per queue. Put the leadership summary on a second tab as a pivot table with two slicers on top. Nobody stomps on anybody’s view, and the summary always reflects the whole dataset because the slicer only slices the pivot, not the source. This is the same layered pattern used in a real-time KPI tracker: input tab for the humans, output tab for the readers.

One tab, standard filters,
=SUMIF(...) totals up top,
someone clicks the funnel,
the sheet goes blank for everyone.

Data tab: raw rows,
  filter views per role.
Summary tab: one pivot,
  two slicers, default set.

Save the filter view URLs into a small “Views” tab so new teammates can find their entry point without hunting through the filter menu. If a filter view falls out of use, delete it — an old view with a stale sort inside it is a landmine for the next person who opens the Data menu and picks the wrong one. And when you do share a Google Sheet across a team, hand out the filter view URL instead of the plain sheet URL so people land where they need to be.

What Apps Script can and cannot do here

Apps Script exposes a narrow slice of both features. Sheet.getFilterViews() lets a script read, create, and delete filter views programmatically, which is useful for spinning up a per-user view when a new teammate joins. Slicers, by contrast, have no first-class Apps Script class as of the latest Sheets service — you can add and configure them through the low-level Sheets.Spreadsheets.batchUpdate Advanced Service, but not through the friendlier SpreadsheetApp. Plan any automation around filter views, not slicers.

Pick the tool that matches the tab

The whole choice collapses into one question: is this tab something people read, or something people edit? A read tab wants slicers on top of pivots, defaults set for the mobile crowd. An edit tab wants filter views, one per role, URLs bookmarked.

• ✓ Summary tab with a pivot → slicer, default state set
• ✓ Raw data tab → one filter view per role, URLs bookmarked
• ✓ Read-only stakeholders → hand out the filter view URL, not the sheet URL
• ✓ Automation planned → build on filter views; slicers have no SpreadsheetApp class yet

Try both on your next new sheet — a summary tab with two slicers, a raw tab with three filter views — and the “someone filtered the sheet and I can’t see my rows” complaint stops arriving in chat.