My tenants model

Some people belong to more than one tenant: a provider admin across end-customers, a contractor, or anyone mid-migration. The My-tenants model is one rule with a few consequences.

The rule: hostname wins

The hostname in your address bar determines which tenant you are acting in. Always.

Same identity, different hostname, different tenant, with different environments, sessions, approvals, records, and roles. Nothing crosses tenants implicitly. One identity can reach acme.preshos.com and globex.preshos.com, but each hostname opens its own tenant with no implicit sharing between them.

Consequences

1. Bookmark each tenant separately and label the bookmarks. Never rely on memory for which tab is which tenant.
2. Check the hostname before consequential actions: role grants, invites, approvals, and any admin change. A grant in the wrong tenant is a real grant in the wrong place.
3. Records do not travel. A session, approval, or outcome in tenant A is invisible from tenant B. When someone “cannot find” a record, ask which hostname they are on first.
4. Roles are per-tenant. Admin in one tenant can be Member in another. Do not assume your powers carried over.
5. Invites are per-tenant. Accept each invite at its own hostname; one acceptance does not join you to the others.

Checklist: working across tenants

• Each tenant bookmarked and labeled
• Before any approval: hostname matches the org whose work this is
• Before any admin change: hostname matches the intended tenant
• When sharing references (sessions, records): include the hostname, not just a name
• When reporting issues: lead with the hostname. It is the fastest disambiguator for support.

Moving between tenants step by step: Switching tenants.

For admins explaining this to users

Tell new members on day one: “Your bookmark is your tenant. If anything looks unfamiliar (wrong data, missing environments, missing powers), check the address bar before anything else.” It resolves the majority of cross-tenant confusion without a ticket.