Users & tenants¶
Admin → Users & access — tabs Users, Roles, Teams and Tenants. Users, teams, tenants and tenant groups are managed by super admins only.
Tenants¶
A tenant is the multi-tenancy boundary — typically a customer or a department.
Creating one¶
Admin → Users & access → Tenants → Create Tenant:
| Field | Meaning |
|---|---|
| Name | Display name |
| Slug | Short name, unique (suggested from the name) |
Creating tenants is a super-admin function — deliberately not exposed as a delegable permission for other roles. A new tenant inherits the instance default for whether the Vesana server may run checks for it itself (see Active collector).
Clicking a tenant expands its details: hosts, collectors, sites, credentials and the tenant's alert grouping.
Copying a tenant¶
Right-click a tenant → Copy Tenant creates a new tenant with all hosts and services (without measurements or history). Check settings and overrides are copied, SNMP communities and check secrets are not — enter those again in the new tenant. The audit entry tenant_copy lists what was left out. A copy counts against the same licence limit as a new tenant.
Deactivating a tenant¶
Deactivate in the context menu shuts a tenant down without deleting it. When you Activate it again, Vesana checks the licence's tenant limit.
Data per tenant¶
After creation, a tenant has:
- 0 hosts
- Default alert-channel templates (empty)
- Audit log
You can create hosts directly; profiles are available across tenants (builtins).
Limits per tenant¶
A tenant is unlimited by default — only the licence's host count applies. To give customers a fixed ceiling (e.g. "customer A may have 50 devices"), set it under Admin → System → Licence → Limits per tenant (collapsed, super admins only). Each tenant has three fields: hosts, checks, collectors.
- Empty = unlimited, 0 = no new ones, otherwise the ceiling.
- A limit only prevents new entries; what already exists stays.
- Next to a limited field you see how much is currently in use.
- When the limit is reached, Vesana answers with a message naming this place.
- Every change is recorded in the audit log (
tenant_limits_update).
Up to v1.9.452 every tenant was fixed at 100 hosts / 1000 checks / 5 collectors, with no way to change it.
Tenant groups¶
Optional, for larger setups: Tenants → Manage groups (super admins only) creates groups such as "Customers North". Use a tenant's right-click menu → Move to group to assign it; a tenant belongs to at most one group. As soon as groups exist, the tenant list is ordered by group.
A group can be the scope of a role assignment: "Team Engineering North · Admin · group Customers North" applies to every tenant in the group — including one you add later. A group that is still used by assignments cannot be deleted.
Deleting a tenant¶
Deleting moves the tenant to the trash — together with all hosts, services, alerts and other objects (shared deletion batch). Restoring it from the trash brings back the whole family. Deleting requires a fresh identity confirmation.
The dialog asks what happens to the tenant's agents and collectors:
- Keep installed (default) — they go dormant. If the tenant is restored, they resume on their own within a few minutes.
- Uninstall — they remove themselves from their devices on next contact (devices with an active local approval refuse and go dormant instead). After a restore they must be reinstalled.
Permanent deletion happens automatically after 30 days, or earlier from the trash. It also removes the tenant's stored credentials, notes and open notifications.
Cross-tenant visibility¶
Every user has a tenant access field: either All (all tenants, including future ones) or a selection of specific tenants. Their base role applies in exactly those tenants. On top come tenants where they have rights via a team or a direct assignment — with the role assigned there. The user switches between their tenants with the tenant selector.
An operator can thus have access to several tenants without being a super admin — and, with assignments, different roles in different tenants.
Users¶
Creating one¶
Admin → Users & access → Users → Create User (super admins only, with identity confirmation):
| Field | Meaning |
|---|---|
| Username | Login — a plain name such as admin is enough, no email address is required (Vesana never emails users) |
| Display name | Name shown in the UI |
| Password | set at creation time; the user changes it afterwards (Settings → Profile → Change Password) |
| Role | Base role — built-in or custom |
| Tenant access | All, or a selection of specific tenants |
Copy User (row action) takes over role and tenant access; you set username, name and password anew.
Accounts from SSO or Active Directory are created by Vesana on first login; the list marks them. For a domain account the directory password applies — a password set in Vesana is only the emergency way in while the directory is unreachable.
Forgot password¶
There is no reset link by email. An admin sets a new password from the user row — this ends all of the user's sessions, and they log in with the new password.
Actions in the user row¶
Every action is available as an icon at the right of the row and in the context menu: edit, copy, set password, Access & teams (see role assignment), Script permissions (on which hosts the user may create or change script-capable checks; without an own setting: admins on all their tenants, every other role nowhere — see Scripts), Sign out all sessions (asks first and reports how many sessions were affected), Reset 2FA (see 2FA), deactivate/activate, delete. Actions that are not possible are greyed out and state why. The list also shows who has TOTP or passkeys set up. A deleted user releases their name immediately — the trash entry carries the deletion date in its name.
Active / inactive account¶
Instead of deleting a user, Deactivate them. Advantages:
- Audit log keeps the user reference
- Re-activation is possible
- Their dashboards stay assigned to them, shares with others remain
A deactivated user can't log in; running sessions and API access end immediately.
Soft delete¶
Deleting moves the user to the trash, where they can be restored or permanently deleted. The audit log keeps the user reference — that this user existed.
A deleted user loses their sessions and API access immediately. The login token of a permanently deleted account never becomes valid again. Deleted users can no longer be edited, reactivated or changed via password/2FA reset.
Moving a user between tenants?¶
Not as a "move" — adjust the user's tenant access instead: add the new tenant to the selection, remove the old one. Different roles per tenant no longer need a second user, just an assignment.
Personal settings¶
Every user under Settings (avatar menu):
- Profile — avatar, username (read-only), display name, change password (for domain accounts in the directory instead of Vesana)
- 2FA — authenticator app, passkeys, backup codes — see 2FA
- Sessions — signed-in devices, sign out individually or everywhere else — see Sessions
- Push — push notifications on this device
- Preferences — light/dark, theme, list appearance, language, show AI assistant and AI analysis, refresh interval
There are no personal API keys. Scripts sign in via the login API with a user account — see API authentication.
Permissions vs. tenant scope¶
Permissions apply per tenant: a user with hosts.create can only create hosts in tenants where one of their roles contains that permission. User, team and tenant management remain super-admin functions; roles may additionally be edited by anyone who holds users.edit_role in all tenants.
Details: Roles & permissions.