Skip to main content
If you have tickets that may contain sensitive information, use visibility groups to restrict who can see a set of tickets. You can configure visibility groups to populate automatically from a filter, manually, or both. Tickets within a visibility group are not generally visible. They are visible to members of the group, and to anyone who normally has access (e.g. assignee, requester).
When you save a visibility group, Serval rechecks every existing ticket in the workspace against it in the background, so matching tickets join and tickets that no longer match leave. New and updated tickets are checked as they change. Tickets added to a group manually stay until someone removes them.

​
Filter tickets by visibility group

On your workspace’s ticket list, open Visibility group and select one or more groups. The list shows tickets that belong to any selected group and that you have access to. Select a group again to remove it, or select All tickets (no group) to clear the selection. Your selection stays in the page URL so you can reload or share it. A view saved to a visibility group always shows that group’s tickets, so its visibility-group selector is locked. If you manage a selected group but aren’t a member, you’ll see its membership panel before the ticket list. Join each selected group you aren’t a member of to view the combined results, or choose Back to all tickets to clear the selection.

​
Adding a visibility group

Managers of a workspace can create visibility groups, configure group settings, and add members who can view tickets within the group. Adding a ticket to a group and removing it is a separate Share tickets with visibility groups action: Managers hold it by default, and it can be granted to other roles through a custom role. To create a visibility group:
  1. Go to Settings -> Ticketing -> Ticket Visibility.
  2. Click + Visibility group in the top right.
  3. Give the group a name, and optionally a description.
  4. Select how tickets join the group:
    • Added manually — someone with Share tickets with visibility groups (Managers by default) adds tickets one at a time or in bulk, from the ticket’s Ticket Visibility section or the ticket list.
    • Matched by a filter — the group covers tickets matching the filter you specify. Conditions can match ticket properties (including your workspace’s custom ticket types), the ticket’s assignment group (available once the workspace has assignment groups configured), the requester’s built-in fields (Department, Job title, Email, Timezone, and Locale), and requester custom fields. Filter conditions can be combined with more than one connector. Conditions joined by AND must all match, and switching a connector to OR starts a new alternative group. A ticket matches the filter when it satisfies any one group.
    • All tickets in this workspace — the group sees every ticket in the workspace, including ones more specific groups also cover.
    • Tickets no other group covers — the group covers a ticket only while no other group does. See Fallback visibility.
  5. Add members to the group.

​
Fallback visibility

A fallback group covers the tickets no other visibility group covers, so uncategorized work has an owner. Unlike All tickets in this workspace, its members see only the leftovers: as soon as another group covers a ticket, the fallback stops covering it, and if that group later stops, the fallback takes it back. Each workspace can have one fallback group. You can set it from the group’s own settings, or from the Fallback visibility card at the bottom of the Ticket Visibility page. A group can be the fallback only if nothing else decides its membership — it can’t also have a filter or cover all tickets.
Setting a fallback changes who can see tickets across the whole workspace. Today, a ticket in no visibility group is visible to everyone in the workspace. Once a fallback covers the leftovers, every ticket belongs to a group — so people who aren’t in any group will only see tickets they requested, are assigned, are subscribed to, or were mentioned in.
As with filter-based groups, saving a fallback rechecks the workspace’s existing tickets, and new or updated tickets are checked as they change.