Back to compare picker

Saved view vs Saved search vs Saved filter vs Table

Choose saved view when the saved object includes display state such as visible columns, column order, layout mode, grouping, density, sort, filters, selected fields, tabs, or default/shared workspace presentation.

Decision dimensions

Dimension Saved viewSaved searchSaved filterTable
UI or UX UI + UX - Persisted named presentation state for a data workspaceUI + UX - Persisted named search criteria for rerunning a dynamic result setUI + UX - Persisted named filter criteria applied to a list, table, board, or dashboardUI + UX - Semantic row-and-column data comparison surface
UI guidance Render saved views as named, selectable workspace presentations with visible owner or visibility, active state, saved layout mode, columns or fields, grouping, sort, filters, and last-updated metadata.Render Save search near the active query and result summary, and show exactly which query text, filters, scope, and sort will be stored.Place Save filter close to the active filter controls and show a criteria preview that names every stored field, operator, and value before users commit it.Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability.
UX guidance Use saved view when users need to return to a complete operational presentation of a changing dataset rather than rebuilding columns, layout, grouping, filters, and sort every session.Use saved search when users repeatedly need the same dynamic result set and must rerun it without rebuilding query, filters, sort, and scope.Use saved filter when users repeatedly apply the same filter values to a changing list and need to reuse those criteria across sessions or teams.Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.
Good UI A support queue has saved views named My urgent tickets, Team backlog, and SLA breach risk, each showing columns, sort, filters, owner, and private or team visibility before users apply it.A search results page shows Save search beside the result count, opens a naming dialog, and previews query, filters, scope, and sort before saving.A case queue exposes saved filters named High priority benefits and My review queue, each with status, team, priority, and date chips before users apply them.A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor.
Bad UI A tab labelled Saved view applies hidden filters, changes columns, and switches layout with no preview or active-state summary.A star icon saves an unnamed search with no confirmation or criteria summary.A star button saves the current table rows without showing which filters created them.A div layout looks like columns but has no caption, table semantics, or header associations.
Good UX A manager opens SLA breach risk, sees the board layout, grouped Status lanes, five saved columns, and current result count, then changes density and saves a private copy instead of overwriting the team view.A user saves a search for Open renewal risks, returns next week, reruns it, and sees newly matching cases included.A benefits worker applies High priority benefits to the current appeal search; the query stays appeal while status, team, and priority filters change.A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.
Bad UX A user changes one column while reviewing a team queue and accidentally updates the shared default for everyone.Saving search stores only the current three results, so future matching records are missing.Saving a filter freezes today's 14 rows, so tomorrow's newly urgent benefits cases never appear.Filtering the table removes selected rows without explaining why or offering a clear-filter path.
Best fit Users repeatedly return to a specific presentation of a changing data set.Users repeat the same search criteria across sessions or operational cycles.Users repeatedly need the same filter criteria on a list, table, board, queue, base view, or dashboard.Records share comparable attributes that users need to scan in aligned columns.
Avoid when Only one current-session filter or sort choice needs to be changed.The query is a one-off lookup that users will not need again.Users only need to adjust filters for the current session.The content is layout, not data.
Required state No saved view selected with current display settings visible and saveable.Unsaved current search with Save search available only when criteria are meaningful.No saved filter selected while current filters are still visible and saveable.Default table state with caption, visible headers, row values, and result count or context.
Accessibility burden Expose active saved-view name, visibility, default status, and modified state in text, not only selected tab styling.Use labelled form fields for saved-search name, description, visibility, and subscription settings.Use labelled controls for saved-filter name, visibility, owner, criteria fields, operators, and values.Use native table semantics for tabular data rather than div-only rows.
Common misuse Saving current rows instead of presentation settings and dynamic criteria.Saving static result IDs instead of reusable criteria.Treating the visible table rows as the saved object instead of storing field, operator, and value conditions.Using table markup to create page columns or layout spacing.

Saved view

UI or UX
UI + UX - Persisted named presentation state for a data workspace
UI guidance
Render saved views as named, selectable workspace presentations with visible owner or visibility, active state, saved layout mode, columns or fields, grouping, sort, filters, and last-updated metadata.
UX guidance
Use saved view when users need to return to a complete operational presentation of a changing dataset rather than rebuilding columns, layout, grouping, filters, and sort every session.
Good UI
A support queue has saved views named My urgent tickets, Team backlog, and SLA breach risk, each showing columns, sort, filters, owner, and private or team visibility before users apply it.
Bad UI
A tab labelled Saved view applies hidden filters, changes columns, and switches layout with no preview or active-state summary.
Good UX
A manager opens SLA breach risk, sees the board layout, grouped Status lanes, five saved columns, and current result count, then changes density and saves a private copy instead of overwriting the team view.
Bad UX
A user changes one column while reviewing a team queue and accidentally updates the shared default for everyone.
Best fit
Users repeatedly return to a specific presentation of a changing data set.
Avoid when
Only one current-session filter or sort choice needs to be changed.
Required state
No saved view selected with current display settings visible and saveable.
Accessibility burden
Expose active saved-view name, visibility, default status, and modified state in text, not only selected tab styling.
Common misuse
Saving current rows instead of presentation settings and dynamic criteria.

Saved search

UI or UX
UI + UX - Persisted named search criteria for rerunning a dynamic result set
UI guidance
Render Save search near the active query and result summary, and show exactly which query text, filters, scope, and sort will be stored.
UX guidance
Use saved search when users repeatedly need the same dynamic result set and must rerun it without rebuilding query, filters, sort, and scope.
Good UI
A search results page shows Save search beside the result count, opens a naming dialog, and previews query, filters, scope, and sort before saving.
Bad UI
A star icon saves an unnamed search with no confirmation or criteria summary.
Good UX
A user saves a search for Open renewal risks, returns next week, reruns it, and sees newly matching cases included.
Bad UX
Saving search stores only the current three results, so future matching records are missing.
Best fit
Users repeat the same search criteria across sessions or operational cycles.
Avoid when
The query is a one-off lookup that users will not need again.
Required state
Unsaved current search with Save search available only when criteria are meaningful.
Accessibility burden
Use labelled form fields for saved-search name, description, visibility, and subscription settings.
Common misuse
Saving static result IDs instead of reusable criteria.

Saved filter

UI or UX
UI + UX - Persisted named filter criteria applied to a list, table, board, or dashboard
UI guidance
Place Save filter close to the active filter controls and show a criteria preview that names every stored field, operator, and value before users commit it.
UX guidance
Use saved filter when users repeatedly apply the same filter values to a changing list and need to reuse those criteria across sessions or teams.
Good UI
A case queue exposes saved filters named High priority benefits and My review queue, each with status, team, priority, and date chips before users apply them.
Bad UI
A star button saves the current table rows without showing which filters created them.
Good UX
A benefits worker applies High priority benefits to the current appeal search; the query stays appeal while status, team, and priority filters change.
Bad UX
Saving a filter freezes today's 14 rows, so tomorrow's newly urgent benefits cases never appear.
Best fit
Users repeatedly need the same filter criteria on a list, table, board, queue, base view, or dashboard.
Avoid when
Users only need to adjust filters for the current session.
Required state
No saved filter selected while current filters are still visible and saveable.
Accessibility burden
Use labelled controls for saved-filter name, visibility, owner, criteria fields, operators, and values.
Common misuse
Treating the visible table rows as the saved object instead of storing field, operator, and value conditions.

Table

UI or UX
UI + UX - Semantic row-and-column data comparison surface
UI guidance
Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability.
UX guidance
Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.
Good UI
A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor.
Bad UI
A div layout looks like columns but has no caption, table semantics, or header associations.
Good UX
A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.
Bad UX
Filtering the table removes selected rows without explaining why or offering a clear-filter path.
Best fit
Records share comparable attributes that users need to scan in aligned columns.
Avoid when
The content is layout, not data.
Required state
Default table state with caption, visible headers, row values, and result count or context.
Accessibility burden
Use native table semantics for tabular data rather than div-only rows.
Common misuse
Using table markup to create page columns or layout spacing.
Decision rules
  • Choose saved view when the saved object includes display state such as visible columns, column order, layout mode, grouping, density, sort, filters, selected fields, tabs, or default/shared workspace presentation.
  • Choose saved search when the saved object is primarily a rerunnable query definition with query text, search scope, ranking, alerts, subscriptions, or search-result lifecycle.
  • Choose saved filter when the saved object is only reusable filter criteria and should preserve the current query, sort, columns, layout, and other view preferences unless explicitly included.
  • Choose table when users need to read the current rows and columns; the table may expose column controls, but it is not itself the persisted view object.
  • A saved view may contain filter and sort settings, but the UI must show which display properties are saved and which current-session changes are only temporary.
  • Use saved view for operational queues, project views, record tabs, CRM lists, support ticket views, and boards where users return to a known presentation over time.
  • Do not call a full saved view a saved filter if it also stores columns, layout, grouping, route, board/list mode, pinned fields, sharing, or default-view behavior.
  • Do not save a static row snapshot unless the interface says it is an export, report, or snapshot; saved views should usually rerender current matching data.
  • When saved views are shared, expose owner, visibility, who can edit, default status, dependency warnings, and a copy path before overwriting team state.
  • When the underlying schema changes, mark missing columns, removed fields, invalid filters, or unavailable grouping rules instead of silently dropping them.
Inspect live examples
Failure modes
  • A saved view says My queue but only stores the current result IDs, so new matching work never appears.
  • Applying a saved view silently changes columns, filters, sort, and grouping with no preview of what will change.
  • A user tweaks a shared operational view and overwrites the team default instead of saving a private copy.
  • A saved filter is used for a full board layout, hiding the fact that columns, grouping, and lane rules are also stored.
  • Removed fields disappear from the saved view without explaining why counts or visible columns changed.
  • Private view names, filters, or counts leak into shared sidebars or dashboard widgets.