Multi Tenancy Worked Examples

Multi-tenancy: worked examples

Part of the Multi-tenancy section. Planned / in design.

The best way to see that one size doesn't fit all — and that FreeITSM bends to each — is to walk through real organisations. Every one below runs on the same design.

1. A one-person IT team (single company)

The biscuit factory runs its own IT service desk. One company, one domain (tastybiscuits.com), one mailbox itsupport@tastybiscuits.com.

→ It's a single-company install. There's a silent Default company, the mailbox is pinned to it, and none of the multi-tenant machinery is visible — no switcher, no domains screen, no triage. It works exactly like FreeITSM does today.

2. The same company grows a second team

Finance asks to come on board, so they add finance@tastybiscuits.com.

→ Not a new company — it's the same business. They connect a second mailbox, still pinned to the one company, and optionally tag it to a Finance department. Multiple mailboxes, one company. Still no switcher.

3. An MSP with one shared inbox

MyMSP supports Acme, Globex and Initech. It tells every client to email support@themsp.com and registers each client's domain (acme.com → Acme, etc.).

→ One shared intake mailbox; the sender's domain sorts each email to the right client. Adding a new client is just "add their domain" — no new mailbox. This is the recommended MSP setup.

4. The forgotten client

MyMSP onboards a new client, d.com, but forgets to set them up. Someone at d.com emails support@themsp.com.

→ The email matches no company, so it lands in triage instead of vanishing. An analyst clicks "create company from this domain", and that email — plus any future d.com mail — is filed automatically from then on. Nothing lost.

5. A business buys another business

The biscuit factory buys the sandwich shop next door (tastysandwiches.com). Sandwich staff are told to email the existing itsupport@tastybiscuits.com, so their mail arrives from a different domain.

→ Nothing breaks: the mailbox is pinned, so it decides the company — the sender's domain is ignored. Whether biscuits and sandwiches should be one company or two is a business decision, not a technical limit:

• One combined desk → change nothing.
• Kept separate → add a second company and either pin a new mailbox to it, or switch the shared inbox to sort by sender domain.

Either way, even if a domain is forgotten, triage catches it.

6. A client demands their own helpdesk address

The sandwich team wants their own itsupport@tastysandwiches.com.

→ Connect it and pin it to the right company (and department). It becomes their inbound and outbound identity — replies go out from it, so it looks like their own helpdesk. People who keep using the old address are simply reassigned (or auto-routed, if you use a shared inbox).

7. The cross-company consultant

Jane is a fractional IT manager who supports three of MyMSP's clients, all from jane@consulting.com.

→ Jane has one self-service login and sees all her tickets across the three clients, each badged. When she raises a new one she picks the client. Her cross-company list is private to her — MyMSP's analysts, working inside each client, never see that Jane also deals with the others.

8. Generalist vs account-aligned MSP teams

• Generalist MyMSP: every analyst supports every client → all analysts get all-company access.
• Account-aligned BigMSP: Jo owns Acme + Globex, Sam owns Initech → each analyst is assigned only their clients.

→ Both run on the same install with no "mode" to choose — staff access is simply a property of each analyst. You can even mix the two.

9. The client with no domain (a known limitation)

A tiny client is a sole trader using a personal gmail.com address.

→ Sender-domain routing can't separate them from anyone else on Gmail. The workaround is to give them a pinned mailbox of their own, so the mailbox identifies them. See Pitfalls and Scope.