Assigning views to users

Route: /users (user drawer), /roles (role drawer), and /views (full-page view editor)

Users only see dashboard tabs for views they can use. A user gets a view when it is assigned to their account, when it is assigned to one of their roles, or when the view is marked All users. You can assign membership on the user, on the role, or on the view.

See also: Overview · Creating and managing views · Users, roles, and permissions

Assign views on a user

1. Open Access Control → Users.
2. Create a user or edit an existing one (Edit / double-click).
3. In the drawer, find the Views search picker (chips of already assigned views plus Search views).
4. Search and select one or more views (including built-in views such as All events, Production events, or Cause and effect events when needed). Scroll the results to load more; the list is not the full catalog at once.
5. Save with Create or Update.

The users table shows assigned views as tags (first two names plus a count if there are more). An empty assignment shows no view tags.

Views granted to All users appear as locked chips with the All users hint. You cannot remove them from the picker, and saving the user does not drop them. Views the user receives through a role appear the same way, marked via role with the role name — see Assigning views to roles and Assign roles and views.

Roles vs views

Roles control permissions (what actions a user can perform). Views control which alerts they can see. Assign both: roles for capabilities, views for visibility.

Assign users on a view

1. Open Access Control → Views.
2. Edit a view (name, double-click, or row Edit) — opens /views/{id}.
3. Under Authorized users, select accounts that should receive this view.
4. Click Update.

See Creating and managing views for the Authorized users field on the view editor.

The views table Users column shows how many members are assigned, or No users assigned.

Assigning views to roles

A view can also be assigned to roles. Every user who holds one of those roles can use the view, without being listed under Authorized users. It is one single setting shown in two places, so you can edit it from either side:

Where	Field	What you do
Access Control → Views → edit a view (/views/{id})	Roles (below Authorized users)	Pick the roles whose members should receive this view, then click Update
Access Control → Roles → edit a role (/roles)	Allowed views (below Allowed KPI Groups)	Pick the views this role grants, then click Update. Choose All views to grant every view, including views created later

Adding a view under Allowed views on a role is the same as adding that role under Roles on the view — see Creating and managing roles — Allowed views.

How membership through roles behaves:

• Dynamic — a user added to the role (manually, by Match Pattern, or by a directory group mapping) immediately gets the role's views; a user removed from the role loses them. Views assigned directly to the account under Authorized users are not affected by role changes.
• Identity-provider roles count — roles a user obtains at login (reverse-proxy role header, SAML group or role matching) grant their views too, even though those users do not appear in the role's Manual Users list.
• All users wins — a view marked All users is visible to everyone regardless of users or roles.
• Built-in views (All events, Cause and effect events, and the other built-in views) are All users views and need no roles. The built-in admin role already sees every view.
• Users page — in the users table and in the user drawer, views that come through a role are marked via role with the role name, including roles that arrive from a reverse-proxy role header (ToBeAlert remembers the roles seen on the user's last requests). You cannot remove them from the user editor; remove the role from the user, or change the view's Roles / the role's Allowed views instead. This works like the locked All users chips.
• Dashboard — nothing changes for the user; the view tabs simply include the views that come through roles.

Which should I use?

Assign views to roles for teams (everyone in noc-operator sees Production events), and to users for exceptions (one auditor who also needs Security triage). Keep both lists short and audit them together.

External authentication

When you use LDAP or SAML providers, Group mappings can assign Views (and roles) when directory groups match. That reduces manual assignment for synced users.

Mapping field	Purpose
Directory group name	Substring match on group DN (LDAP) or SAML group claim
Assign views	Views granted when the mapping matches
Assign roles	Roles granted when the mapping matches

Use * as the group name in a mapping to apply views to every synced user (use carefully).

When users have no views

If an account has no views — none assigned directly, none through its roles, and no All users view (and it is not treated as full admin visibility) — the dashboard cannot load a default view and shows an error such as No default view found or You have no assigned views. Assign at least one view before the user works on alerts.

Administrators with the admin role bypass normal view scoping for visibility.

Best practices

1. Roles for teams, users for exceptions — assign team views on the role (Allowed views / Roles) and keep Authorized users for one-off access.
2. Standardize on one place — either maintain membership on the view, on the role, or on the user, and audit the others periodically.
3. Least privilege — give All events only to admins or auditors who need every alert; use All views on a role only for roles that should see everything.
4. Pair with roles — a read-only role plus a narrow view limits both actions and data.
5. Onboard with templates — duplicate a view per team, then assign it to the team's role.
6. Revisit after org changes — remove old views and roles from departing users to avoid stale tabs; views marked via role go away when the role is removed.