Every Versus tenant has a tenant admin who manages their own team — inviting users and assigning roles from the Tenant Admin console, backed by the Versus identity platform. No separate identity tooling required.
When your organization is provisioned, Versus creates a dedicated identity organization for you on the Versus IdP and appoints your first tenant admin — usually the person who requested the tenant. From then on, your tenant admin runs your team's access entirely from inside the product, under Tenant Admin in the sidebar:
Because this is scoped to your identity organization, a tenant admin can only ever see and manage users in their own tenant. There is no way to reach another organization's users, and the highest platform role (Super Admin) is reserved for Versus staff and can never be granted from this console.
From Tenant Admin → Users, click Invite User, enter their email (optionally a name), pick a starting role, and send. The new user receives an email from the Versus IdP to set their password and enrol multi-factor authentication (MFA) before their first sign-in.
Versus uses a simple, level-based role model. A user has exactly one role at a time; changing it takes effect on their next sign-in. From the console a tenant admin can assign:
| Role | Level | What they can do |
|---|---|---|
| Tenant Admin | 4 | Full control of the tenant, including inviting users and assigning roles in this console |
| Operator | 3 | Day-to-day operations — run workflows, manage certificates and virtual services |
| Viewer | 2 | Read-only access to inventory, dashboards, and reports |
To change someone's role, pick a new one from the dropdown next to their name on the Users page. To revoke access, deactivate them (reversible) or remove them (deletes the account from your organization).
Where your users' accounts actually live depends on how your tenant is deployed. This is the single most important distinction for a tenant admin to understand, because it changes what you manage in this console versus what your identity team manages elsewhere.
Tenants at <you>.versus-demo.com. Versus is your directory — no identity setup on your side.
Tenants at <you>.versus-one.com. You connect your own identity provider (Okta, Microsoft Entra ID, Ping, Google, or any OIDC/SAML IdP).
Put simply: on the Versus IdP, the Tenant Admin console is where user accounts are born, because Versus is your directory. With a bring-your-own IdP, the accounts already exist in your corporate directory and flow into Versus through single sign-on — so the console's job narrows to deciding what each person can do in Versus (their role), while who exists, how they authenticate, and when they're offboarded stays with your identity team.
Demos and evaluations should be frictionless — asking a prospect to stand up SAML federation just to try the product would get in the way, so demo tenants get a turnkey directory on the Versus IdP with a real tenant admin from day one. Production deployments, by contrast, are expected to plug into an organization's existing single sign-on so that access follows the same joiner/mover/leaver controls as every other corporate application. The tenant-admin experience is deliberately the same in both models; only the source of the user accounts changes.
Can a tenant admin grant Super Admin? No. Super Admin is a Versus-staff platform role and is never available from the Tenant Admin console — the assignable set is Viewer, Operator, and Tenant Admin.
Can I have more than one tenant admin? Yes — assign the Tenant Admin role to as many users as you need.
Can a tenant admin see another company's users? Never. Every action is scoped to your own identity organization, enforced server-side.