> ## 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. *** ## Display modes Views support three display modes: Detailed analysis with customizable columns. Choose which fields to display and adjust column widths for your preferred layout. Custom fields are hidden by default and are grouped separately in the column visibility menu, where you can show or hide them individually. **Edit fields inline** Update a ticket without leaving the table view. Click any editable cell to change the value in place — Ravenna saves the change immediately and re-renders the row with the new value. You can edit the following columns inline: * **Due date** and **Start date** * **Custom fields** of type Text, Number, Date, Boolean (toggle), Select, and Multi-select Other custom field types (User, Application, Access level, File, and similar resource pickers) stay read-only in the table. Open the ticket to edit them from the detail view. Cells become read-only when you don't have permission to edit that ticket, so members with view-only access still see the values without an editable affordance. Streamlined readability with essential ticket information. Compact format for scanning through tickets quickly. Visual workflow management with columns organized by status or other criteria. Drag tickets between columns to update their status. Collapse columns to focus on specific workflow stages. **Collapse and expand columns** Collapse columns you're not actively working with by clicking in the column header. Collapsed columns display vertically with the column name and ticket count. Expand collapsed columns by clicking anywhere on them or the expand button. Empty columns collapse by default. Your preferences save per view and don't affect other team members. Dropping a ticket on a collapsed column expands it automatically. *** ## Create views Create views to save specific configurations for different workflows or responsibilities. Click the **+** button in the Views section of your sidebar. Set the view name and add an optional emoji. Choose whether the view should be private (visible only to you) or shared with your workspace. On a shared view, toggle **Allow edits** to control whether other workspace members can promote their changes back to the shared configuration. **Allow edits** is off by default, so only the view's owner and workspace admins can save changes for everyone. See [Lock shared views](#lock-shared-views) for details. Click **Create** to save the view. It appears in your sidebar navigation. Views appear in your sidebar navigation and can show unread ticket counts for new activity. *** ## Customize views Configure how tickets are filtered, grouped, and sorted in each view. Apply filters to focus on relevant tickets: * **ID** and **Short ID**: Filter by a ticket's full ID or its short ID using **equals**, **does not equal**, **is any of**, or **is not any of**. Use this to jump to specific tickets, exclude known ones, or pull a list referenced from another tool (for example, paste a set of short IDs from a spreadsheet). * **Status**: Filter by open, resolved, or closed tickets * **Assignee**: Show tickets assigned to specific team members. Use the **is member of** or **is not member of** operator with this filter, or with **Requestor** or **Author**, to match tickets whose user belongs to one or more selected user groups. This is useful for following a team rather than a single person. * **Priority**: Focus on high, medium, or low priority tickets * **Due date**: View tickets due within specific time ranges, or filter for tickets with no due date set * **Channel**: Filter tickets from specific channels * **Category**: Filter by ticket category * **Tags**: Filter by ticket tags * **CSAT score**: Filter tickets by their CSAT score (1-5 stars), or filter for tickets without a score * **SLA**: Filter tickets by the SLA applied to them, or by SLA health status (On Track, Alert, Breached, Met). Use this to surface tickets approaching a deadline or already in breach. * **SLA target**: Filter tickets by which SLA target types they have — Time to first response, Time to resolution, or Time to close. You can also filter for tickets that have any SLA target applied, or tickets with no SLA targets at all. Use this to focus on a specific commitment type (for example, only tickets tracked for first response). * **Custom fields**: Filter by any custom field values Group tickets into logical categories: * **Status**: Group by ticket status * **Assignee**: Group by assigned team member * **Assignee group**: Group by the user group that the assignee belongs to * **Priority**: Group by priority level * **Parent ticket**: Group by parent ticket relationships * **Channel**: Group by channel * **Category**: Group by ticket category * **Custom fields**: Group by custom field values Sort tickets to prioritize your work: * **Creation date**: Newest or oldest first * **Priority**: Highest or lowest priority first * **Due date**: Soonest or latest due date first * **Title**: Alphabetical order * **Updated date**: Most recently updated first * **CSAT score**: Highest or lowest customer satisfaction rating first * **Custom fields**: Sort by any sortable custom field on the workspace's request types. Text, Text area, Number, Date, Time, Duration, Boolean, Select, and Timezone select fields appear under the **Custom Fields** group in the sort menu. Select and Duration fields sort by the display order of their options, so ascending puts the first-defined option first. Timezone select fields sort as text. Multi-select, Tag, and User fields aren't sortable. When you modify filters, display modes, grouping, or sorting for a view, your changes persist automatically. Your configuration is preserved every time you return to that view. In table views, clicking **Reset Columns** restores default column visibility and hides any custom field columns. You can re-show custom fields from the column visibility menu. Use the search box at the top of the menu to quickly find a column by name when you have many fields. ### Personal overrides on shared views On any custom view (any view other than the workspace default), your filter and display-option changes are saved as a **personal override** that only affects you. The shared view's saved configuration stays the same for everyone else until you explicitly promote your changes. Personal overrides cover: * **Filters** added, removed, or edited from the filter bar * **Display mode** (Table, List, or Kanban) * **Column visibility, column order, and column widths** in table views * **Grouping** and **sorting** This lets you adjust a shared view to your workflow without disrupting teammates. For example, you can narrow **My team's open tickets** to just your channel for the afternoon, and no one else sees the change. **Save or reset your overrides** When you have unsaved filter changes on a custom view, **Save** and **Reset** buttons appear next to the filter bar: * **Save** promotes your current filters to the shared view's configuration. Everyone using the view sees the new filters the next time they load it. * **Reset** discards your personal filter overrides and reverts to the shared view's saved filters. The view options menu shows an indicator when your column, grouping, sorting, or display-mode choices differ from the shared view. From that menu you can: * **Save view options to view** to push your current display settings to the shared view. * **Reset view options** to discard your personal display overrides and return to the shared configuration. The **workspace default view** does not use personal overrides. Filter and display-option changes there save directly to the view and apply to anyone who hasn't customized it. Personal overrides are stored per user, per view. They follow you across browsers and sessions, and they don't affect other workspace members. ### Lock shared views Shared views have an **Allow edits** toggle that controls whether other workspace members can promote their personal overrides back to the shared configuration. * When **Allow edits** is **off** (the default), the **Save**, **Save for all**, and **Save view options to view** actions are hidden from non-owner, non-admin members. Everyone can still tweak filters, columns, sorting, and display mode for themselves — those tweaks continue to save as [personal overrides](#personal-overrides-on-shared-views) — but only the owner and workspace admins can push those changes into the shared view. * When **Allow edits** is **on**, any workspace member who uses the view can save their changes back to the shared configuration, matching the previous default behavior. The view's owner and workspace admins always bypass the lock. They see **Save** and **Save view options to view** regardless of the **Allow edits** setting. Toggle **Allow edits** from the view's edit dialog. You can change it at any time, and it takes effect immediately for everyone using the view. Locking a shared view only affects who can promote changes for the whole team. Personal overrides — filters, columns, sorting, grouping, and display mode scoped to you — keep working exactly the same way for every member. ### Duplicate views Any workspace member can duplicate a view from the sidebar to create their own copy without touching the original. To duplicate a view, hover over it in the sidebar, open its menu, and select **Duplicate**. The copy appears in the sidebar named ` (copy)`. **What the copy inherits** * The duplicate is created **private** and owned by you, so it only shows up in your sidebar. * **Allow edits** is off, matching the default for new shared views. If you later make the copy shared, other members won't be able to promote changes to it unless you turn **Allow edits** on. * The duplicate captures **your effective view** — the shared view's saved configuration overlaid with your personal filter and display overrides. This means the copy reflects what you were actually looking at, including any filters you narrowed, columns you toggled, or sort orders you changed for yourself. It does not just clone the owner's shared definition. * The emoji, table (Tickets, Users, and so on), and containing collection are copied from the original. Duplicating is useful when you want to fork a shared view to experiment with different filters, keep a personal variant of a locked team view, or hand a starting point to another teammate by making your copy shared later. ### Edit and delete views Workspace members can edit shared views. Private views can only be edited by their owner. To delete a view, click the view options menu and select **Delete**. Private views can only be deleted by their owner. Shared views can be deleted by any workspace member. *** ## Create tickets from a view When you create a ticket while a view is active, Ravenna pre-fills the new ticket form with values from the view's filters. This saves you from re-entering fields that are already implied by the view you're working in. **How defaults are applied** Ravenna looks at each filter on the active view and pre-fills the matching field on the new ticket when: * The filter uses an **equals** or **is any of** operator. * The filter targets a single value (for example, *Assignee equals Alex*, not *Assignee is any of Alex, Sam*). Ravenna can pre-fill the following fields: * Assignee * Status * Priority * Category * Tags (all tag values from matching filters are added) If a filter matches multiple values or uses a different operator (such as *is not* or *contains*), Ravenna skips that field. **Where this applies** * **Ticket list and table views**: clicking **New ticket** opens the create dialog with defaults from the view's filters. * **Kanban views**: clicking **+** on a column adds the column's grouping value (status, priority, or assignee) on top of the view's filter defaults. Column values take precedence when both are set. You can still change any pre-filled field before submitting the ticket. Defaults only seed the form — they don't constrain what you can create. Ravenna only applies filter defaults to new tickets. They have no effect when you duplicate an existing ticket. *** ## Organize with collections View collections provide a folder-like structure for organizing multiple related views. Collections reduce clutter in your sidebar navigation by grouping related views together. ### Create collections Click the **+** button in the Views section of your sidebar and select **New Collection**. Give it a descriptive name based on the views you'll group (e.g., "Project Alpha", "Support Team", "Weekly Reviews"). Choose private or shared. Private views can only be placed in private collections. Public views can only be placed in public collections. Drag and drop views into the collection from your sidebar. Collections can be edited and deleted by their owner or any workspace member (for shared collections). Private collections can only be managed by their owner. *** ## Work with views ### Switch views Click any view in the sidebar to instantly apply its configuration. This updates your filters, grouping, sorting, and display mode to match the selected view's settings. ### Export tickets Export tickets from any view to a CSV file for reporting or analysis. Navigate to the view containing the tickets you want to export. Click the **Export** button in the toolbar. The CSV file downloads with all tickets matching the current view's filters. The file is named using the view name and current date (e.g., `My_Tickets_2026-01-13.csv`). **What's included in the export** Each row in the CSV represents one ticket. Exported columns mirror the columns currently visible in the view's table configuration. Hiding a column from the table excludes it from the export, and showing a column adds it back. This gives you control over which fields land in the CSV without filtering the resulting file afterward. Available columns cover the core ticket properties used across views, including: * Ticket ID, title, and description * Status, priority, category, and tags * Channel and workspace * Requester and assignee * Created, updated, due, and resolution timestamps * SLA name and current SLA status (On Track, Alert, Breached, or Met) * CSAT score (when available) * Custom field values configured on the ticket's form **Custom field columns** Each custom field you've added to the view appears as its own column in the CSV, using the field's label as the header. Values are formatted to match how they display in Ravenna: * **Select** and **Duration**: the selected option's label (e.g., `Critical`). * **Multi-select**, **Tag**, **User multi-select**, and **Application multi-select**: a comma-separated list of labels (e.g., `Frontend, Backend`). * **Boolean**: `Yes` or `No`. * **Date**: `YYYY-MM-DD`. * **Text**, **Number**, and other single-value types: the raw value. Empty custom fields export as a blank cell. Hide a custom field column from the table before exporting if you don't want it in the CSV. To customize what gets exported, adjust column visibility from the view's table settings before clicking **Export**. Shared views use the shared column configuration, so changes affect every member who uses that view. The export honors the view's active filters, so applying filters such as status, assignee, or SLA status before exporting limits the file to a focused dataset. ### Share view URLs Views are accessible through direct URLs. Bookmark specific views or share them with team members by copying the URL from your browser. Switching views updates the browser URL automatically. ### Unread notifications Views display notification badges showing the count of unread tickets that match the view's criteria. These badges indicate which views contain new activity. ## 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 status (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.