Saved search

Problem Context

• The product has large search, issue, work item, document, case, ticket, inbox, or audit-log result sets.
• Users return to the same criteria over time, across sessions, or across teams.
• Saved searches can become shared operational artifacts that drive dashboards, alerts, queues, exports, and team workflows.

Selection Rules

• Choose saved search when users need to store and rerun a named query or criteria set across sessions.
• Use saved search when results should remain dynamic and include records that match the saved criteria in the future.
• Show Save search only after there is meaningful criteria to preserve, such as query text, filters, scope, sort, or advanced clauses.
• Use clear names and criteria summaries so users can recognize what will run before they open or subscribe to a saved search.
• Expose owner, privacy, shared audience, favorite state, last updated, and alert subscription state when saved searches can affect teams.
• Ask whether to update the saved search or save a copy when users change criteria after opening an existing saved search.
• Use recently searched for passive query history and recently viewed for opened items; neither should look like an intentionally saved search.
• Use filter panel controls when users are still building current criteria rather than managing a persisted query object.
• Use saved filter as a separate pattern when users save only reusable filter values without query text, result scope, sort, alert, or shared saved-view lifecycle.

Required States

• Unsaved current search with Save search available only when criteria are meaningful.
• Save dialog or inline form with name, criteria summary, visibility, and optional description.
• Saved search selected state with name, result count, criteria summary, owner, visibility, and management actions.
• Modified-from-saved state where current criteria no longer match the saved definition.
• Shared or private state with clear audience and edit permissions.
• Subscribed alert state with schedule and unsubscribe path.
• Deleted or unavailable saved search state with explanation and recovery path.
• Empty saved-search list state with a path back to create one from active search criteria.

Interaction Contract

• Saving stores query criteria, filters, sort, and scope as a reusable definition, not just the current result IDs.
• Running a saved search loads its criteria, updates the result count against current data, and visibly marks the active saved search.
• Changing criteria after running a saved search creates a modified state until the user updates the saved search, saves a copy, or discards changes.
• Sharing exposes who can view, run, edit, copy, subscribe to, or delete the saved search.
• Favorites affect quick access only and do not change query criteria or sharing.
• Subscriptions or alerts use the saved criteria and show enough schedule and ownership detail to audit future notifications.
• Deleting or losing permission to a saved search removes it from quick access while preserving understandable recovery or explanation.

Implementation Checklist

• Capture the canonical search representation, including query text, filters, sort, scope, and advanced syntax.
• Show a criteria preview before save and in the saved-search detail header.
• Require a meaningful name and prevent duplicate names from becoming indistinguishable.
• Store owner, visibility, shared audience, favorite state, description, updated time, and alert subscription state.
• Provide explicit Run, Edit, Save copy, Share, Subscribe, Favorite, Rename, and Delete paths where those actions exist.
• Warn before overwriting a shared saved search or changing criteria that drive alerts, dashboards, queues, or exports.
• Use permission-aware lists so private saved search names, criteria, and result counts do not leak.
• Show result counts as current data, and explain when counts differ from the last run because matching records changed.

Common Generated-UI Mistakes

• Saving static result IDs instead of reusable criteria.
• Using a star or bookmark as the only save action without showing name, criteria, owner, or visibility.
• Overwriting a shared search when the user intended a temporary refinement.
• Mixing saved searches with search history, recently viewed items, saved filters, and browser bookmarks.
• Letting subscriptions, dashboards, or exports depend on saved searches without showing the underlying criteria.
• Leaking private saved-search names or result counts in shared sidebars, dashboards, or notification lists.

Critique Questions

• Can users tell exactly which query, filters, sort, and scope will be saved?
• Does rerunning the saved search use current data rather than an old result snapshot?
• Is it clear whether the search is private, shared, favorited, subscribed, or owned by someone else?
• When criteria change, does the UI distinguish update saved search from save copy and temporary run?
• Can users manage stale, deleted, duplicated, or permission-denied saved searches without breaking their workflow?
• Are saved searches visually separate from recent searches, recently viewed records, saved filters, and bookmarks?