Overview
Saved views reduce repetitive setup and improve consistency across teams.
They should be lightweight, shareable, and easy to manage at scale.
Restore and govern recurring workspace context
Apply, search, create, rename, duplicate, and set default views; then test schema drift and the guided repair state.
Account workspace
Saved views
3 views
Renewals this month
Personal- Filters
- Stage: RenewalClose date: This month
- Sort
- Renewal value ↓
- Columns
- Account · Owner · Value · Close date
Renewals this month applied
Anatomy
Use each piece in this order to keep interpretation and automation consistent.
- 1View record
Name, owner, tags, and visibility level.
- 2Configuration payload
Filters, sorting, columns, and hidden settings.
- 3Scope
Personal or team/shared visibility status.
- 4Default indicator
Signals default startup view when available.
- 5Actions
Rename, duplicate, delete, and set default.
The ordering here is not visual-only; it reflects interaction priority and expected user cognition. Keep this order unless policy demands a specific domain exception.
When to use
Use this pattern when the user needs guided consistency, state, and reuse at scale.
Recommended
- Operational dashboards
For users who return to the same workspace context.
- Complex filter trees
When setup is too expensive for each session.
- Team templates
Standardize onboarding views for common tasks.
When not to use
Avoid forcing this pattern where simpler, direct interactions are sufficient.
Avoid
- Highly dynamic contexts
Avoid for screens where conditions change every minute.
- Very simple lists
Use no-view mode for single list layouts.
- Strict security scopes
Avoid exposing cross-tenant config snapshots without checks.
Variants
A small number of variants helps teams choose correctly without adding complexity.
Personal
Visible only to creating user.
Shared
Team-wide reusable query and view profile.
Locked
Standardized and non-editable governance views.
States
States communicate readiness, risk, and expected user behavior.
| State | Trigger | Visual response | Interaction |
|---|---|---|---|
| No views | First use | Empty list + create CTA | Prompt user to save current state. |
| Synchronized | View selected | Controls apply immediately | Selection stays in sync with active view. |
| Stale | Source schema changes | Warning indicator | Offer view refresh or remap. |
Behavior
Behavior should remain predictable across devices, permissions, and async edges.
Context persistence
Persist as a deterministic config object.
Conflict-aware restore
Reconcile deleted fields and stale columns gracefully.
Sharing workflows
Handoff team views with minimal setup.
Accessibility
Keep interaction clarity high and ensure assistive technologies get the same meaning.
| Key | Action |
|---|---|
| Ctrl/CmdS | Save current UI state as a new view if supported. |
| ArrowDown | Navigate quickly between saved view list items. |
| Enter | Apply focused saved view. |
- Announce if a saved view fails validation after schema changes.
- Use explicit labels for sharing and visibility state.
- Provide sufficient contrast for default indicators and status chips.
Content guidelines
Consistency is achieved by language standards, not by design only.
Naming
Use team terminology and context.
Regional open incidents - EMEA
Descriptions
Capture intent and scope in one line.
Monitored view for escalated high-priority incidents.
Ownership
Show owner and last edited details.
Shared by Maya · updated 2h ago
Examples
Reference implementation style, payloads, and practical behavior.
Production use
- Persist at save points to avoid accidental snapshots during transient setup.
- Use shared templates for on-call and release teams.
- Mark stale saved views with recovery actions instead of silent breakage.
Props / API
Use these API entries as a baseline contract and validate them against your domain layer.
These names are implementation-oriented and should map to your local contracts.
Props