> ## Documentation Index > Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt > Use this file to discover all available pages before exploring further. # Views > Save personalized ticket views with display preferences, filters, and sort settings to streamline triage and recurring workflows in Ravenna. Views organize tickets by saving your display preferences, filters, and sorting settings. Each view provides quick access to different workflows and ticket organizations. ## Mental model A view is a saved lens over a workspace's tickets. Views do not contain tickets. They define a combination of filters, sorting, grouping, and display mode that determines which tickets are shown and how. The underlying ticket data is the same regardless of which view is active. Key distinction: channels are containers (every ticket belongs to exactly one channel), while views are filters (a ticket can appear in many views simultaneously if it matches their criteria). Views belong to a workspace. They can be private (visible only to the creator) or shared (visible to all workspace members). Collections group related views into folders in the sidebar. Custom views (any view except the workspace default) layer two configurations: the **shared view configuration** that everyone sees, and an optional **personal override** for the current user. When a user tweaks filters, display mode, columns, grouping, or sorting, the change is stored as their personal override and does not affect anyone else. The user must explicitly **Save** filter changes or **Save view options to view** to promote their override into the shared configuration; **Reset** clears the override and falls back to the shared configuration. The workspace default view does not support personal overrides — changes there save directly to the shared configuration. Shared views additionally carry an **Allow edits** flag. When it is off (the default for new views), the **Save** / **Save view options to view** actions are hidden from non-owner, non-admin members, so only the owner and workspace admins can promote personal overrides into the shared configuration. Personal overrides themselves are unaffected — every member can still adjust the view for themselves. Duplicating a view is available to any member and creates a private, `allowEdit: false` copy owned by the caller, seeded with the caller's *effective* configuration (shared config overlaid with their personal overrides) rather than the raw shared definition. *** ## View design recommendations **Common shared views for a workspace:** | View name | Filters | Grouping | Purpose | | -------------------- | ------------------------------------ | -------- | --------------------------------- | | Unassigned | Assignee: none, Status: open | Channel | Triage queue for incoming tickets | | My tickets | Assignee: current user, Status: open | Priority | Personal work queue | | High priority | Priority: high/urgent, Status: open | Assignee | Escalation visibility | | Waiting on requester | Status: waiting | Due date | Follow-up tracking | | Recently resolved | Status: done, Updated: last 7 days | Channel | Review and quality check | **When to create a new view vs. use an existing one:** * Create a new view when a team member or team needs a repeatable way to see a specific slice of tickets. * Do not create views for one-off queries. Ad-hoc filtering without saving serves that purpose. * Shared views are better for team workflows (triage, escalation). Private views are better for individual preferences (my assignments, my channels). **Display mode selection:** * Table for data-heavy analysis, reporting, and when custom field columns matter. * List for quick scanning and high-volume ticket processing. * Kanban for status-driven workflows where dragging tickets between stages is the primary interaction. *** ## Filter and grouping patterns Effective views combine filters and grouping to answer specific questions: **Triage pattern:** Filter by status (open) and assignee (none). Group by channel or category. This surfaces all unhandled tickets organized by where they came from or what they are about. **Workload balancing:** Filter by status (open, in progress). Group by assignee. This shows how tickets are distributed across the team and highlights imbalances. **SLA monitoring:** Filter by SLA outcome (Alert or Breached) to focus on tickets that need immediate attention, or filter by a specific SLA to track compliance for a single agreement. Filter by SLA target to narrow to a specific commitment type, such as Time to first response or Time to resolution. You can also isolate tickets with no SLA targets at all. Combine with sorting by due date (soonest first) to prioritize work. **Cross-channel oversight:** No channel filter, group by channel. This gives a workspace-wide view of ticket distribution across channels. Filters use AND logic. All active filters must match for a ticket to appear. There is no OR logic within a single view. To see tickets matching either condition A or condition B, create two separate views. *** ## Collections Collections are folders for views. Use them when a workspace has enough views that the sidebar becomes cluttered. Recommended collection patterns: * **By role:** "Managers", "On-call", "New hires" with views tailored to each role's needs. * **By process:** "Triage", "Escalation", "Review" grouping views by workflow stage. * **By project or initiative:** Temporary collections for time-bound efforts. Privacy rules: private views can only go in private collections. Shared views can only go in shared collections. You cannot mix privacy levels within a collection. *** ## Ticket creation defaults from filters When a user creates a ticket from inside a view, Ravenna seeds the new ticket form with defaults derived from the view's active filters. This reduces redundant data entry when a view already implies the field's value. Rules: * Only filters using **equals** or **is any of** operators are considered. * A default is only applied when the filter targets a single value. Multi-value filters (e.g., *Assignee is any of Alex, Sam*) do not produce a default. * Eligible fields are: assignee, status, priority, category, and tags. Tags accept all matching values from the filters. * On Kanban boards, the column's grouping value (status, priority, or assignee) takes precedence over the filter default for that field. * Defaults are never applied when duplicating an existing ticket. This behavior is automatic and requires no configuration. Users can override any pre-filled value before submitting the ticket. *** ## Constraints and gotchas * Views are workspace-scoped. A view cannot span multiple workspaces. * On custom views, filter and display-option changes auto-save as personal overrides scoped to the current user. Other workspace members are unaffected until the user promotes the override via **Save** (for filters) or **Save view options to view** (for display options). **Reset** discards the personal override and falls back to the shared configuration. * The workspace default view does not use personal overrides. Edits there save directly to the view and affect anyone who hasn't customized it. * Personal overrides include filters, display mode, column visibility/order/width, grouping, and sorting. They are stored per user, per view. * Private views are only visible to and editable by their creator. Shared views can be edited or deleted by any workspace member. * Shared views have an **Allow edits** flag that gates the **Save** / **Save view options to view** actions for non-owner, non-admin members. The default is off, so newly created shared views are locked until the owner or an admin opts in. Owners and workspace admins always bypass the lock. Personal overrides are unaffected by the flag. * Any workspace member can duplicate a view from the sidebar's view menu. Duplicates are always created private, `allowEdit: false`, and owned by the caller. The duplicate captures the caller's effective view (shared configuration overlaid with their personal filter and display overrides), not the raw shared configuration. * Filters use AND logic only. For OR conditions, create separate views. * Kanban column collapse preferences are per-user, per-view. They do not affect other team members. * Unread notification badges on views reflect tickets matching the view's filters that have new activity. They update in real time. * CSV exports include all tickets matching the current view's filters at the time of export. The export reflects the live data, not a cached snapshot. * CSV exports follow the view's column visibility settings. Hidden columns are excluded from the file, so confirm your column configuration before exporting.