Multi Tenancy

Multi-tenancy

🛠️ Status: in active development — not yet in a release. The tickets module is now solid for real multi-company use: the foundation, ticket scoping, email routing (pinned/shared mailboxes, domain and individual-sender routing, triage, diagnostics), the first per-company settings (ticket types & origins), full ticket-layer data isolation, and per-analyst company access are all built. Still to come: per-company departments/SLAs, the self-service portal, and rolling scoping through the other modules. See the progress tracker for the live state, and the pinned roadmap issue (#24) for discussion.

🟢 If you run FreeITSM for a single company, none of this will affect you. Multi-tenancy is opt-in and invisible unless you deliberately add a second company (see below).

Multi-tenancy lets a single FreeITSM install support multiple, separate client companies — each company's data walled off from the others — so one deployment can serve many clients at once. The main audience is MSPs and IT providers who today need a separate install per client.

The guiding idea: one size doesn't fit all

The single most important design principle here is that organisations are not all the same, and FreeITSM should bend to how you work — not force you into one rigid shape. A solo IT team, an MSP funnelling every client through one inbox, and an MSP that dedicates a mailbox per client are all valid, and all supported by the same system.

The way we achieve that, again and again, is a simple rule:

Flexibility lives in the entity, not in a global "mode" switch.

Rather than a single setting that says "this install works like X", each mailbox, each analyst, each piece of config carries its own behaviour — and the different ways of working simply emerge from how you set them up. There is no "MSP mode" to flip. You compose the behaviour you want. The Worked Examples page shows several very different organisations all running happily on the same design.

Invisible until you need it

Every install starts with a single, silent Default company that quietly owns everything. With one company there is no company switcher, no email-domain mapping, no triage queue, and no split settings — the app looks and behaves exactly as it does today. All of the multi-tenant machinery only wakes up the moment you create a second company. Existing installs upgrade cleanly: your current data simply belongs to the Default company, and nothing changes unless you choose to grow.

Pages in this section

Page	What it covers
Concepts & vocabulary	Tenant vs department, analyst vs requester, what a "mailbox" really is
Email routing & mailboxes	The two mailbox types, company domains, how an email finds its company, the triage safety net
Settings: global vs per-company	Which settings are shared, which are per-company, and the "no mode switches" principle
Users & self-service	One login that spans companies, who sees what, knowledge-base visibility
Staff cross-company access	The company switcher, "all companies" search, and assigning staff to clients
Worked examples	Real-world organisations, from a one-person IT team to a multi-client MSP
Pitfalls & gotchas	The traps to avoid and how the design protects you
Data isolation & the audit	How one company's data is walled off from another — the mechanism, and the three-sweep audit that hardened it
Scope: what it's for (and isn't)	Where FreeITSM fits, and the enterprise needs we deliberately don't chase

A note on terminology: "tenant" is the technical word for a separate client company. In the interface you'll mostly see friendlier words like company or client. This wiki uses them interchangeably.