“Which company URL did I use for this account?” is a bad way to begin a login.
It sounds like a password problem. Usually it is an account-model problem.
Many support products grew up around the tenant first: create a help desk, then create users inside that help desk. It is a tidy shortcut. Each workspace gets its own people, permissions, login surface, and little island of reality. Right up until the same human needs to work in two islands.
Then the shortcuts start charging interest. They need a second account. They may need a second password reset. They need to remember which subdomain contains which job. Removing them from one company can look uncomfortably like deleting them. The software knows the workspace very well. It is less sure who the person is.
The better split is simple: isolate the data by workspace, but keep the human identity global. A workspace grants access to a person; it does not become the person’s account.
The tenant-first shortcut
A tenant-scoped user model is easy to explain at the whiteboard:
- A company creates a workspace.
- An admin adds people to it.
- The user record carries the company, role, and all the access rules.
For a team with one workspace and no plans to change that, it works. Plenty of software got useful this way.
The trouble is that the data model quietly says a person is a property of the company they happen to be helping today. Agencies, consultants, fractional support leads, founders with multiple products, and people who change employers all discover the assumption eventually. The software has to manufacture a new version of the same human every time the workspace changes.
That leaks into ordinary operations.
Login becomes a scavenger hunt. The user needs the workspace URL before the service can even decide which account they mean. Zendesk’s agent-login guidance, for example, tells agents to use the sign-in page for the account subdomain they want and offers a subdomain reminder when they do not know it. That is documented behavior, not an accusation of bad engineering.
Account discovery becomes private knowledge. A person may know they have access somewhere but cannot ask the product, “Which workspaces am I in?” They need a bookmark, an invitation email from six months ago, or the colleague who remembers the URL. A perfectly modern software experience, if by modern you mean a filing cabinet with OAuth.
Switching becomes a second login flow. Support people who work across client accounts should be able to move between permitted workspaces deliberately. They should not need to collect tabs, passwords, and browser profiles like souvenirs.
Offboarding gets dangerous. Removing somebody from one workspace should remove one relationship. If the account is fused to that workspace, every lifecycle action needs extra care not to erase the person’s access elsewhere, profile, or credentials.
Freshdesk illustrates why this deserves careful language rather than a cheap competitor dunk. Its standalone Freshdesk documentation describes agents and admins using an account subdomain to log in, while Freshworks’ newer Neo Admin Center documents centralized user profiles and a switcher across accounts and products. The newer direction is the point. Account-first patterns are common because they are a reasonable starting point. They just stop being a good boundary once people belong in more than one place.
Tenant isolation is still non-negotiable
Global accounts do not mean global access. This distinction is where otherwise sensible conversations become slightly haunted.
Tickets, customer records, internal notes, queue settings, analytics, and billing data still belong to a workspace. A person with access to two workspaces should not get an accidental combined inbox, a cross-company customer search result, or a very exciting privacy incident.
The global part answers: who is this person?
The membership answers: what can they do here?
Those are different questions. Treating them as one field on one user record is convenient only while the answer to “here” never changes.
The membership is where a product should keep the information that actually varies by workspace: role, active or suspended status, team, customer organization, ownership, seat usage, and preferences that affect local work. An admin can be an admin in one workspace, an agent in another, and a customer in a third. The account did not become confused; the product finally described the real world.
What changes for the person using the product
The visible improvement is pleasantly boring.
You log in with one account. The product can show the workspaces you are allowed to enter. You pick one, and the session is scoped to that workspace. Your role and permissions are evaluated there. Switching does not merge data; it changes context.
Leaving a workspace also gets the right meaning. You lose access to that workspace, and any workspace-scoped credentials can be revoked. Your account remains intact. So do your memberships elsewhere. That is how people expect access to work, which is often a useful hint.
This is especially helpful in support because roles are rarely portable in the simple sense. A consultant might need agent access for one client, admin access for another, and customer access to a vendor’s portal. Forcing all that into a single tenant-scoped user shape is how you end up explaining an exception with a spreadsheet named final_final2.
The complexity did not disappear
This is not a magic global-user button. It moves the complexity to the place where it belongs and makes it explicit.
You now need membership lifecycle rules:
- what happens when an invited person already has an account
- how a pending invitation becomes active
- who can suspend or remove a membership
- what happens to ownership when the owner leaves
- which credentials must be revoked when access ends
- how a person discovers and switches only to workspaces they can enter
Those are not edge cases. They are the product. A global identity model is worth the work because it gives each action an honest target: add access, change access, remove access, or delete the account. No guessing whether “remove user” means “remove them from this queue” or “delete a human from the internet.”
It also does not solve every identity problem. SSO, SCIM, cross-workspace data access, and fine-grained permissions still need their own design. A clean membership model gives those systems a sensible place to attach; it does not make them disappear in a puff of well-normalized smoke.
The boring rule that saves future you
Model people once. Model their relationship to each workspace separately.
That rule keeps login simple without weakening tenant isolation. It makes switching a normal navigation action instead of a credential ritual. It makes offboarding precise. And it lets the data model reflect a mildly inconvenient truth about SaaS: people move around.
The implementation details are where the real traps live—invites, active context, scoped tokens, and deletion rules. The technical follow-up walks through those boundaries and the migration lessons behind them.