Overview

Views define which alerts a user is allowed to see. Each view includes an Alerts Query that filters the alert dataset; users who have that view — assigned directly, through one of their roles, or because the view is marked All users — get a matching tab on the Alerts dashboard. Views are separate from dashboard sidebar filters: views set the access boundary; filters narrow results within the active view tab.

Step	What you configure	Menu / route	Documentation
1	Views — name, description, alert query, Authorized users, Roles	Access Control → Views → /views	Creating and managing views
2	Membership — which views each account or role can use	Access Control → Users → /users · Access Control → Roles → /roles	Assigning views to users · Assigning views to roles
3	Dashboard usage — switch tabs, counts, ordering	Alerts → Dashboard → /dash	Applying views on the dashboard

Where to find it in the UI

In the sidebar under Access Control:

• Views → /views

The page title is Views. Header actions:

Button	Purpose
Refresh	Reload the views table
Create view	Open the full-page editor at /views/new

Table search, sorting, pagination, and bulk selection follow the shared list pattern — see TQL search and filters and List tables and bulk actions. Click the name, the row Edit button, or double-click a row to open /views/{id}. There is no create/edit drawer.

Permissions

Managing views requires administrator access. Non-admins do not see Access Control or Views in the sidebar. Assigning views to users is also done under Access Control → Users, and assigning views to roles under Access Control → Roles (Allowed views).

Built-in views

Four views are Built-in (lock icon in the Name column). They cannot be duplicated or deleted. You can open them (name, double-click, or Edit) and change only Authorized users, including All users. Name, Description, and Alerts Query stay locked.

Name	Purpose
All events	All alerts (SELECT * FROM Alerts)
Production events	Open production alerts with severity minor, major, or critical
Events in maintenance mode	Alerts in maintenance status
Cause and effect events	Alerts that are a cause or an effect (is_cause = true OR is_effect = true) — see Cause and effect alerts

Built-in views still appear in the list for administrators. They are All users views, so they need no roles; you can still adjust Authorized users from the view editor or from each user record, like any other view.

How views fit together

Typical rollout for a platform team:

1. Create a view Staging platform with Alerts Query environment = 'Staging'.
2. Assign that view to the staging on-call role (Allowed views on the role, or Roles on the view), or to individual users under Users — see Assigning views to roles.
3. Those users open Dashboard and select the Staging platform tab; only matching alerts load.
4. They apply sidebar filters (severity, time range, custom filters) on top of that view.

LDAP and SAML external auth providers can map directory groups to views during sync so new users receive views automatically.

Related modules

Module	Relationship
Users, roles, and permissions	Assign views per user or per role; roles also control what users can do
Roles	Allowed views grants views to every member of the role; permissions stay separate from view visibility
Alerts dashboard	One tab per view the user can use (direct, via role, or All users)
Sidebar filters	Further filter within the active view
External auth providers	Group mappings can assign views after directory sync
Policies	Policies modify alerts; views limit which alerts a user sees

Best practices

1. Model teams or environments with views (for example Production NOC, Staging, Security) instead of one view per person.
2. Keep queries testable — design in TQL with the live alert preview, then switch to SQL only when you need the raw SELECT.
3. Assign team views on roles (Allowed views / Roles) and keep Authorized users for exceptions, so membership follows role changes automatically.
4. Avoid giving every user All events unless they need full visibility; prefer scoped views.
5. Document view purpose in Description so admins know when to assign each view.
6. Review membership when people change teams; remove old views before adding new ones.