Users & tenants¶
Admin → Access — "Tenants" tab and "Users" tab.
Tenants¶
A tenant is the multi-tenancy boundary — typically a customer or a department.
Creating one¶
Admin → Access → Tenants → New:
| Field | Meaning |
|---|---|
| Name | Display name |
| Slug | URL slug, unique |
| Branding | Logo, color (for status pages and PDFs) |
| Notes | optional |
Creating tenants is a super-admin function — deliberately not exposed as a delegable permission for other roles.
Data per tenant¶
After creation, a tenant has:
- 0 hosts
- 0 custom dashboards
- Default alert-channel templates (empty)
- Audit log
You can create hosts directly; profiles are available across tenants (builtins).
Deleting a tenant¶
Soft delete cascades: all hosts, services, and alerts of the tenant get soft-deleted too (shared deletion batch) — restoring in the trash UI brings back the whole family.
Permanent deletion after 30 days or via admin purge.
Cross-tenant visibility¶
Every user has a tenant access field: either all (all tenants, regardless of role) or selected (an explicitly assigned list of tenants). Super admins typically have all; a regular user with selected only sees the tenants assigned to them and switches between them via the tenant dropdown at the top left.
This is independent of role: an operator can have access to several tenants at once without being a super admin — just assign them multiple tenants when creating/editing the user.
Users¶
Creating one¶
Admin → Users & Tenants → Users → New:
| Field | Meaning |
|---|---|
| Username | Login — a plain name such as admin is enough, no email address is required (Vesana never emails users) |
| First / last name | Display name |
| Tenant access | all, or a selection of specific tenants |
| Role | Default or custom |
| Active | Toggle |
| Password | set at creation time; the user changes it afterwards (Settings → Security) |
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 (from v1.9.437): edit, set password, deactivate, Log out all sessions (asks first and reports how many sessions were affected), Reset 2FA (see 2FA). 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, set Active = false. Advantages:
- Audit log keeps the user reference
- Re-activation is possible
- Dashboard ownership relationships persist
An inactive user can't log in; all tokens are invalidated.
Soft delete¶
A real delete is a soft delete (see Trash). The audit log still keeps the user reference — that this user existed.
Login tokens vs. DB user
Active login tokens contain the user ID. On soft delete the user stays in the DB — existing tokens remain valid until they expire. After the final purge, the user vanishes from the DB without old tokens causing server errors.
Moving a user between tenants?¶
Not a direct "move" — instead, just adjust the user's tenant access: add the new tenant to the selection, remove the old one. For genuinely separate logins (different roles per tenant needed), a second user entry with a different email address helps.
My account view¶
Every user under "My account":
- Username (read-only after creation)
- Change display name
- Change password
- Set up 2FA (authenticator app or security key) — see 2FA
- Language (DE/EN)
- Theme
- AI visibility
- Manage API keys
API keys (personal access tokens)¶
An alternative to browser login for CLI/scripts:
"My account" → API keys → New:
- Name + expiry date
- Scope (read-only / read-write)
- The token is shown exactly once
In requests: Authorization: Bearer <token>.
Revocable any time; the old token hash is invalidated.
Permissions vs. tenant scope¶
Permissions are tenant-scoped: a user with hosts.create can only create hosts in the tenants they have access to. Role and tenant management themselves remain super-admin functions.
Details: Roles & permissions.