Skip to main content

Multi-tenancy and Delegated Administration

Nevis ID separates user populations with tenants and models organizations as hierarchical unit trees with no fixed depth limit, so delegation follows your real structure rather than a preset number of levels. Delegated administrators hold predefined roles, from Helpdesk to tenant root, and every right is bounded by a dataroom, Nevis's term for what the industry calls tenant isolation, data segregation, and scoped admin visibility: authorization for a unit always includes its subunits and never the parent unit, so a B2B partner administrator manages exactly their own organization's subtree and nothing beyond it, on the SCIM 2.0 REST API as on every other interface. Authorizations attach to profiles rather than directly to users: one person authenticates with a single set of credentials and acts through multiple profiles, for example a scoped administrator profile in one unit and an end-user profile in another, so even the most far-reaching delegated rights remain traceable to one accountable individual. Each tenant carries its own policies, templates, and default unit, every customer additionally runs on a dedicated, isolated instance, and tenants, units, profiles, roles, and authorizations are fully administrable over the REST APIs, with an administrator's effective permissions queryable at any time.

Also known as

delegated administration, tenant isolation, data segregation, scoped admin visibility, data rooms.

At a glance

CapabilityDetails
TenantsTenants (called clients in the Nevis data model and APIs) separate user populations inside an instance, each with its own policies, templates, and default unit; user identifiers are scoped per tenant
Tenant isolationTwo layers: a dedicated, isolated instance per customer, and tenants segregating populations inside the instance; see also Deployment, Architecture, and Data Residency
Organizational hierarchyUnits form hierarchical trees with no fixed depth limit; moving a unit moves its entire subtree and creating top-level units requires a separate permission
Delegated administrationPredefined administrator roles from tenant root (ClientRoot) and user administration (UserAdmin) to Helpdesk and SelfAdmin; which roles an administrator may access and assign is itself configuration
Scoped admin visibilityA dataroom bounds an administrator's reach across tenants, units, and applications, on every interface including the SCIM 2.0 REST API: a partner organization's administrator reaches only the users of their own organization; authorization for a unit includes all its subunits and never the parent unit
Multiple profiles per userA user can hold several profiles, each belonging to one unit and carrying its own authorizations, under a single set of credentials; effective permissions derive from the login profile, and every action stays traceable to the individual
Permission modelRoles bundle elementary permissions (AccessControl.*); every management endpoint documents the permission it requires; callers can query their own effective permissions
Enterprise rolesTenant-specific bundles of application roles for organization-wide entitlements, assigned per profile
Self-service administrationEnd users manage profile, devices, sessions, and login methods in the self-service app; administrators manage any user's sessions and devices with dedicated admin permissions
B2B partner administrationDelegation scopes a partner administrator to their organization's unit subtree; organization lifecycle and onboarding are covered under B2B and Organization Management
Provisioning and onboardingSCIM 2.0, just-in-time creation, bulk import, and invitation onboarding; see Integration, APIs, and Provisioning and Registration, Onboarding, and Identity Verification
Audit of administrative changesEvery administrative change is recorded with actor and timestamp in a history-enabled data model, with append-only audit logs; see Reporting, Analytics, and Audit

Concepts

How-to Guides

References