Multi Tenancy Users and Self Service

Multi-tenancy: users & self-service

Part of the Multi-tenancy section. Historical design note — what shipped differs. The shipped model gives each portal user a single company via users.tenant_id (tickets they raise are filed there; no company falls to triage) rather than the one-global-person model sketched below. See Self-Service Portal for the shipped behaviour; this page is kept for the design discussion.

End users are where multi-tenancy gets genuinely interesting, because it touches identity — who someone is when they log in or email in.

One person, one login — tickets sorted per company

A requester is a single global person, identified by their verified email address — one account across the whole install. But each ticket they raise belongs to one company, chosen at the moment the ticket is created (automatically if the person has only ever dealt with one client; otherwise with a simple "which company is this for?" prompt).

When they sign in to the self-service portal, they see every ticket they've raised, across all the companies they deal with, each clearly badged with the client it belongs to.

Why this isn't a data leak

It can feel alarming — a person seeing tickets across companies! — but it isn't a breach, because the isolation boundary is "Company A must not see Company B's data", never "a person can't see their own data". Someone viewing their own tickets across the clients they personally work with is just seeing their own stuff. (It also neatly handles the consultant who genuinely supports three of your clients — see Worked Examples.)

The guardrails (these always hold)

1. The cross-company view is private to that person. It exists only in their own portal session. From inside a company, your analysts never see that a requester also has tickets with another client (which would leak that, say, an Acme contact also works with a competitor).
2. "Raised by me" only. It does not become a company-wide view across clients; any company-wide visibility stays within a single company.
3. Verified email is the identity — email verification is required for a self-service account.

A welcome side effect: simpler logins

Because a requester is one global person, "log in with your email" is unambiguous again. That means you do not need a separate portal web address per client just to make login work. Per-company branded portals and per-company single sign-on remain perfectly possible as future niceties — but they're optional, not a prerequisite.

Knowledge-base visibility

Knowledge articles need two independent dials, and getting the combination right is what keeps content from leaking:

• Scope — this company only vs global (shared across all clients, e.g. your MSP's universal how-tos).
• Audience — internal (staff only) vs published (visible to end users).

A requester should see their company's published articles plus any global published ones — and nothing belonging to another company.

Self-registration

If end users can self-register, accounts are bound to a company by their verified email domain — so email verification is essential, and people on free-email or unrecognised domains can't be placed automatically (they'd be invited by your team instead).