Saved filter

Problem Context

• The product has operational lists, record tables, ticket views, case queues, boards, dashboards, or base views with recurring filter criteria.
• Users need personal and team shortcuts for criteria such as status, owner, priority, segment, date range, stage, tag, or assignment group.
• Filter presets may control work queues or limited views, so silent changes can hide urgent work or expose records.

Selection Rules

• Choose saved filter when users need to preserve and reapply a named set of filter values, operators, and fields across sessions.
• Use saved filter when the result set should stay dynamic and include records that match the criteria later.
• Show criteria summaries before Apply, Save, Update, or Share so users can predict exactly which filters will change.
• Preserve query text, sort order, page size, selected columns, and view mode unless the saved object explicitly includes those properties.
• Separate private, team, and global presets with owner and visibility labels before users can overwrite or delete them.
• Use filter panel for the current criteria builder and saved filter for the persisted reusable preset created from it.
• Use filter chips to display and remove active criteria after a saved filter has been applied.
• Use saved search instead when users save query text, search scope, ranking, subscriptions, reports, dashboards, or a full named result view.
• Use sort controls when the saved object only changes ordering, not which records are included.
• Treat invalid or permission-denied criteria as a recoverable preset state instead of silently ignoring them.

Required States

• No saved filter selected while current filters are still visible and saveable.
• Saved filter list with active, private, team, global, owner, and last-updated states.
• Criteria preview that lists each field, operator, and value included in the preset.
• Applied preset state with criteria chips, result count, and separate query and sort summary.
• Modified-from-saved state when current filter values no longer match the active preset.
• Save as new state with name, visibility, and duplicate-name handling.
• Update existing state with shared-filter warning when the preset affects other users.
• Invalid criterion state for removed fields, missing options, permissions, or unsupported operators.
• Empty saved-filter list state with a path to save the current filter criteria.
• Deleted or unavailable preset state that explains why the saved filter cannot be applied.

Interaction Contract

• Saving stores filter criteria definitions, not the current result IDs.
• Applying a saved filter replaces the relevant filter fields and leaves unrelated search, sort, column, and view state unchanged unless documented otherwise.
• The UI visibly marks which saved filter is active and whether the current criteria have diverged from it.
• Updating a preset changes future applications of that saved filter and should warn when the preset is shared or drives a queue.
• Duplicating or saving a copy preserves the current criteria while assigning a new owner, name, and visibility.
• Clearing the saved-filter selection removes the active preset identity without clearing all current filters unless the user chooses Clear filters.
• Deleting or losing access to a preset removes it from saved-filter lists and explains any affected queue, tab, dashboard, or shortcut.
• Invalid criteria remain visible with an edit or remove path so users understand why result counts changed.

Implementation Checklist

• Persist canonical filter criteria as field, operator, value, and conjunction data rather than display labels or row IDs.
• Render a human-readable criteria summary in the saved-filter list, active banner, save form, and update confirmation.
• Store owner, visibility, shared audience, applicable object or table, last updated time, and whether the preset is system, private, team, or global.
• Keep query text and sort order in separate state unless the saved-filter model includes them and the UI says so.
• Detect duplicate names within the same visibility scope and require enough disambiguation for private and shared presets.
• Warn before updating, deleting, or broadening a saved filter used by a team queue, default view, dashboard, automation, or report.
• Validate saved criteria against current schema, permissions, and available option values before applying them.
• Announce apply, save, update, copy, invalid-field, and delete outcomes through a stable status region.

Common Generated-UI Mistakes

• Treating the visible table rows as the saved object instead of storing field, operator, and value conditions.
• Treating every saved view as a saved filter even when it also saves columns, sorting, route, chart settings, or query text.
• Applying a preset that clears query text or sort order without warning.
• Using only color, position, or a star icon to show the active saved filter.
• Mixing saved filters with saved searches, recent searches, recently viewed records, and bookmarks.
• Silently dropping invalid criteria and widening the result set.

Critique Questions

• Can users tell which exact field, operator, and value criteria are stored before applying the preset?
• Does applying the saved filter preserve unrelated query, sort, and view state unless the UI explicitly says otherwise?
• Is it clear who owns the preset, who can see it, and whether updating it affects a team queue?
• Can users distinguish temporary filter edits from Update saved filter and Save as new?
• What happens when a saved criterion references a field, option, or record the user can no longer access?
• Are saved filters visually and behaviorally separate from saved searches, filter chips, current filter panels, bookmarks, and recent history?