Overview

Users are the accounts that sign in to ToBeAlert and receive permissions through roles. Each user has a login, profile fields, optional Roles and Views, and an active or inactive Status. Local users authenticate with a password; directory or SSO users are provisioned through External auth providers.

Step	What you configure	Menu / route	Documentation
1	User account — login, name, email, password (local)	Access Control → Users → /users	Managing users
2	Roles — permission sets (search picker in the user drawer)	User drawer or Access Control → Roles → /roles	Roles overview · Assign roles and views
3	Views — alert visibility (search picker; All users and via role views stay locked)	User drawer, Access Control → Views → /views, or Allowed views on a role	Views · Assigning views to users
4	External auth — LDAP/SAML provisioning (optional)	Access Control → External Providers → /external-providers	External auth providers

Where to find it in the UI

In the sidebar under Access Control:

• Users → /users

The page title is Users. Header actions:

Button	Purpose
Refresh	Reload the user table
Create user	Open the create-user drawer

When your license limits enabled users, a counter (for example 12/50) appears next to Refresh with the tooltip Enabled users (active accounts vs license limit).

Permissions

Managing users requires administrator access. Non-admins do not see Access Control or Users in the sidebar. If Create user is disabled or a crown icon appears, your license may have reached the enabled-user limit — contact your administrator or vendor.

How users fit together

Typical local operator setup:

1. Create a user with Login, Name, and Password on the Managing users page.
2. Assign one or more Roles (for example a custom role with alert read/write scopes).
3. Assign Views so the user only sees alerts for their team — or let the role do it through Allowed views (those views show as via role).
4. Leave Status active (green toggle) so the account can sign in.

Typical LDAP setup:

1. Configure an LDAP provider and run Sync Users — see External auth providers.
2. Open Users, find synced accounts (Auth source shows the provider name or local).
3. Assign Roles and Views manually; enable inactive synced users if your provider leaves them disabled.
4. Keep local login enabled in Backend Config → Authentication until external login is verified.

Users without an Email cannot receive email notifications when assigned directly on notification rules — prefer notification groups and keep emails up to date.

License limits

Resource	When limited
Enabled users	Create user may be unavailable; counter shows enabled users vs limit; warning icon when the limit is reached

Disabled (inactive) users typically do not count toward the enabled-user limit.

Related modules

Module	Relationship
Users, roles and permissions	Role definitions and permission reference
Views	Views assignable in the user drawer, or granted through roles (Allowed views)
External auth providers	LDAP/SAML login and user sync
Backend Config — Authentication	Auth Required, local_login_enabled, signup, token expiry
Notification groups	Groups reference users by account

Best practices

1. Least privilege — assign the smallest role set that covers the user’s job.
2. Views for alert scope — use views for team boundaries; grant them on the role (Allowed views) for teams and on the user for exceptions.
3. Email on every operator — required for direct email notifications and audit clarity.
4. Disable before delete — disable accounts when someone leaves; delete only when you must remove history ties.
5. Protect built-in accounts — built-in users (lock icon) cannot be deleted; you cannot disable your own account.
6. Coordinate auth changes — test LDAP/SAML before disabling local login.
7. Audit last login — review Last login periodically for stale accounts.