Saved view

Problem Context

• The workspace has a changing data set such as records, tickets, issues, projects, orders, assets, opportunities, tasks, alerts, or audit entries.
• Users can configure several presentation properties, such as table versus board layout, visible fields, column order, grouping, filters, sort, density, or tabs.
• Different roles need different operational views of the same underlying data.
• Saved views may be private, team, global, default, pinned, duplicated, embedded in dashboards, linked from navigation, or used as work queues.
• Schema, permissions, fields, teams, and data change over time, so saved views need stale or invalid-state handling.

Selection Rules

• Choose saved view when users need to persist a named combination of layout, columns, grouping, filters, sort, density, and other display preferences for a data surface.
• Use saved search when the saved object is mainly query criteria, search scope, ranking, subscriptions, or rerunnable search behavior.
• Use saved filter when only reusable filter values should be stored and query, sort, columns, and layout should remain separate.
• Use table, list view, board, calendar, or dashboard layout for the actual current presentation; saved view is the management layer that stores how that presentation is configured.
• Use custom dashboard when users compose multiple widgets, charts, or cross-source summaries rather than one configured result surface.
• Use pinned items or favorites when users only need quick access, not saved display state.
• Use a static export or report when users need a fixed snapshot rather than current records rendered through saved criteria and layout.
• Avoid saved view when users cannot predict which settings will be saved or when shared updates cannot be permissioned or audited.
• Avoid saved view for one-off column hiding that does not need naming, reuse, sharing, defaulting, or recovery.
• Avoid using saved view names, counts, or criteria in shared navigation when they reveal private or unauthorized data.

Required States

• No saved view selected with current display settings visible and saveable.
• Saved view list with active, private, team, shared, pinned, default, owner, last-updated, and result-count states.
• Applied saved view state with view name, layout, columns, filters, sort, grouping, and count summary.
• Modified-from-saved state when current display settings no longer match the saved definition.
• Save as new, update existing, duplicate, rename, share, set default, pin, and delete states.
• Shared-view update warning when changes affect other users, dashboards, queues, or navigation links.
• Invalid saved view state for removed columns, missing fields, permission-denied filters, unavailable grouping, or unsupported layout.
• Empty saved-view list state with a path to save the current presentation.
• Deleted or unavailable saved view state with explanation and replacement route.
• Narrow-screen state that preserves active view identity and access to view actions without hiding critical status.

Interaction Contract

• Saving stores a canonical view definition, not a static list of current row IDs.
• Applying a saved view changes only the settings listed in its preview and updates the result set from current data.
• The active saved view name, visibility, and modified state remain visible near the data surface.
• Temporary changes to columns, filters, sort, grouping, density, or layout create a modified state until the user updates, saves a copy, or discards changes.
• Updating a shared or default view confirms audience, dependencies, and edit permission before the saved definition changes.
• Duplicating a saved view preserves the current configuration while assigning a new owner, name, visibility, and optional tab placement.
• Invalid or unavailable saved settings remain visible with repair paths instead of silently broadening results or hiding columns.
• Deleting or losing access to a saved view explains affected shortcuts, dashboards, default routes, or team queues.

Implementation Checklist

• Define the canonical view model: data source, layout mode, visible fields, field order, filters, sort, grouping, density, tab placement, owner, visibility, and default status.
• Show a human-readable view summary before Apply, Save, Update, Duplicate, Share, Set default, or Delete.
• Separate view state from row selection, transient scroll position, temporary search text, and one-off local UI state unless the product explicitly includes those settings.
• Store owner, visibility, editable audience, last updater, updated time, dependency use, and whether the view is private, team, global, system, pinned, or default.
• Detect modified-from-saved state whenever saved columns, filters, sort, layout, grouping, or density differ from the active definition.
• Validate saved columns, filters, grouping fields, and permissions against the current schema before applying the view.
• Warn before updating or deleting a saved view used by dashboards, shared tabs, queues, automations, reports, or default navigation.
• Test duplicate names, private and shared permissions, invalid fields, mobile view action access, keyboard management, and screen-reader announcements.

Common Generated-UI Mistakes

• Saving current rows instead of presentation settings and dynamic criteria.
• Calling a saved filter a saved view while hiding that columns, layout, grouping, and sort are also stored.
• Overwriting a shared or default view when the user intended a temporary personal adjustment.
• Applying a saved view with no preview of changed columns, filters, sort, grouping, or layout.
• Mixing saved views with saved searches, saved filters, recent views, exports, and bookmarks in one list.
• Silently dropping invalid columns or permission-denied filters and changing the visible result set.
• Leaking private view names, criteria, counts, or columns in shared tabs or dashboards.
• Making the active view look like a normal tab without showing modified or unsaved changes.

Critique Questions

• Which display settings are stored in this saved view, and can users inspect them before applying or updating it?
• Does applying the view rerender current data rather than a stale row snapshot?
• Is it clear who owns the view, who can see it, who can edit it, and whether it is a default or shared operational queue?
• What happens when users change columns, filters, sort, grouping, or layout after opening a saved view?
• How are removed fields, unavailable grouping, invalid criteria, or permission changes repaired?
• Would saved search, saved filter, table, dashboard, favorite, pinned item, or static export better match what users are trying to preserve?