Switching Tenants
A user linked to more than one tenant can switch between them, and the platform lists the ones they may reach.
Where to find it
Architect Panel → Configuration:
- Multitenancy — the tenants themselves
- Custom Tenant Information Fields — your own fields on a tenant
- Instance Configuration Fields — settings held per tenant
Architect Panel → Configuration:
- Site Settings — where a user lands after signing in
Only linked tenants appear
The list a user is offered comes from their own links and their groups. So switching is not a way to reach a tenant somebody does not already have access to — it is a convenience over access they already hold.
Where they land
Sign-in can take a user to a tenant page or straight to the administration panel, which is an installation-level choice. For a user with several tenants, landing somewhere that makes the current tenant obvious is worth more than saving a click.
The current tenant must be unmistakable
The whole risk of switching. Somebody who believes they are in one customer’s tenant and is actually in another will create records in the wrong place, send a message to the wrong customer, or delete something that was not theirs.
The tenant name should be visible at all times, not on a page nobody looks at.
Encourage a habit
Check where you are before doing anything consequential. That sounds trivial and it is the control that actually works, because no interface prevents somebody acting on an assumption.
Switching does not change permissions
A user has whatever groups they hold in the tenant they switch to, which may be quite different. Somebody who is an administrator in one and a read-only user in another will find things missing, and that is correct.
Activity is recorded per tenant
Which means an action taken in the wrong tenant is recorded there. That is how such a mistake is found afterwards — and a reason the tenant should be obvious at the time, not reconstructed later.
Support access deserves a marker
If your own staff switch into customer tenants, consider making that visibly different from a customer’s own session. It reduces mistakes and it is the honest thing to show the customer in their activity log.
Worked example
A platform shows the current tenant name in the header at all times and lands multi-tenant users on a page that names it explicitly. Support sessions are visually marked. A consultant working across three customers reported the header as the thing that stopped repeated mistakes.
Recommendations
- Show the tenant name always, not on one page.
- Land multi-tenant users somewhere that names it.
- Mark support sessions visibly.
- Build the habit of checking before acting.