Switching tenants

Switching tenants is moving one identity between isolated customer footprints. The model is My tenants: the hostname in the address bar determines which tenant you are acting in, always. Same identity on another hostname is another tenant, with different environments, sessions, approvals, records, and roles.

How switching actually works

/my-tenants shows a Memberships card listing every tenant your identity can open. The page states the rule outright: open a tenant on its hostname; session authorization is hostname-wins; there is no in-app organization switcher.

• Each row names the tenant with its hostname underneath, plus Current and active badges on the tenant you are signed into now.
• Each row has an Open link. That link is the switch: it opens that tenant on its own hostname (bookmark it separately).
• Partner admins and multi-org members use this list to move between customer workspaces. One acceptance does not join you to the others; each tenant has its own invite.

There is no in-app organization switcher. Each row opens its tenant on its own hostname.

Checklist

• Bookmark each tenant separately and label the bookmarks. Never rely on memory for which tab is which tenant.
• Before any approval, check the hostname matches the org whose work this is. Before any admin change, check it matches the intended tenant.
• When someone “cannot find” a record, ask which hostname they are on first. Records do not travel across tenants.
• Roles and invites are per-tenant. Admin in one tenant can be Member in another; one acceptance does not join you to the others.
• When reporting issues, lead with the hostname. It is the fastest disambiguator for support.

The full model: My tenants. First-time setup: Day-0.