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 [email protected].

→ 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 [email protected].

→ 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 [email protected] 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 [email protected].

→ 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 [email protected], 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 [email protected].

→ 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 [email protected].

→ 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 sole trader on Gmail)

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 — so you map their exact address as a specific sender ([email protected] → that company), which is checked before the domain. Their mail routes correctly while everyone else on Gmail is unaffected. You can set it up on the company's page, or in one click from the triage queue the first time they email. (A dedicated pinned mailbox is the alternative if you'd rather give them their own address.) See Pitfalls and Scope.