Add tenants beneath the one you manage
A new tenant is created beneath the tenant you are currently acting as. Give it a name and it joins the hierarchy, with its key generated for you.
Multi-tenancy
One installation, every tenant kept in its own lane.
Run subsidiaries or business units as tenants inside a single OneView installation, each with its own data, access and permissions.
Tenant hierarchy
Build the structure that matches your institution.
Model your group as a hierarchy of tenants and manage it from one Tenants page, without separate deployments.
Rename and move as the group changes
Rename a tenant or move it under a different parent when your structure changes. You can only change tenants inside the part of the hierarchy you manage.
Search and see your capacity
Search tenants by name or key. The page shows how many tenants your license allows and how many you have used. The top-level tenant does not count against that limit.
Available when your license includes it
Multi-tenancy is a licensed module. The Tenancy section and the tenant switcher appear only on installations that hold it, and a single-tenant installation looks and behaves exactly as it always has.
Tenant-scoped data and access
Each tenant sees its own work.
Working records are tied to a tenant, and every request carries the tenant the user is acting in. A user who is not a member of a tenant is refused.
Transactions
Each transaction belongs to a tenant, so monitoring only works on the activity of the tenant you are acting in.
Verifications
Verification records are kept against the tenant that ran them.
Cases
Cases belong to a tenant, so each team works its own caseload.
Reports
Regulatory reports, and the transactions and people attached to them, stay with the tenant that prepared them.
Teams
Teams are scoped to a tenant, so case ownership follows the tenant structure.
Integration access
A service account is bound to one tenant and resolves its tenant from that binding, never from a header a caller could change.
Customers across tenants
Shared customers, separate relationships.
Tenants are separate for day-to-day work, but a customer of your institution stays a single customer.
One customer, one record
Customers belong to the institution, not to a single tenant. Customer identity is unique across the whole installation, so the same person is not duplicated for every tenant that serves them.
Each tenant keeps its own relationship
Every tenant that deals with a customer has its own relationship record, with an open or closed status and the dates it opened and closed, so each tenant's history with that customer is clear.
You only see what your scope allows
Customer relationships and related-party links are limited to the tenants the signed-in user is allowed to read.
Switching and permissions
Move between tenants without mixing them up.
People who work across tenants move between them deliberately, and their access is always resolved for the tenant they are in.
- 01
Switch tenant
Users who belong to more than one tenant get a tenant switcher in the app. Switching clears what was loaded for the previous tenant, so nothing carries over.
- 02
Permissions follow the tenant
A user can hold a different role in each tenant they belong to. After switching, the application shows what their role in that tenant allows.
- 03
Join a branch, within limits
Authorized users can request membership in a branch under their home tenant. Each branch sets which roles are eligible, and the grant is recorded in the activity log.
- 04
Roll up across branches
Users with the right grant can view cases for This branch, This branch and below, or All branches. Rollups are for viewing, and each one is recorded for audit.
Start a conversation
Request a demoReady to run your whole group from one installation?
See how tenants, tenant-scoped access, shared customers and tenant switching come together in one OneView installation.