Multi Tenancy Scope

Multi-tenancy: scope — what it's for (and what it isn't)

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

Part of "one size doesn't fit all" is being honest about the sizes FreeITSM is not trying to fit. Knowing where it stops is as useful as knowing what it does.

What it's for

• A single company running its own service desk (the default, and completely unaffected by any of this).
• An MSP or IT provider supporting multiple client companies from one install, with each client's data walled off.
• Small-to-mid-sized organisations who value a broad, low-cost, self-hosted toolset.

What it's deliberately not for

FreeITSM aims to be lightweight, broad, AI-assisted and self-hosted. Some requirements would force it to become a heavy enterprise/compliance platform and lose exactly what makes it useful. We choose, on purpose, not to chase these:

• Physically separate databases per client, data-residency guarantees, per-client encryption keys / HSMs, or cryptographic "right to erasure". Our model is one database with logical separation and a single master key. If your client's auditors require physical isolation, FreeITSM is not the right fit.
• A signed-up, hosted SaaS that we run and bill for. FreeITSM is self-hosted — you run it.
• Reseller / sub-tenant hierarchies (an MSP whose clients are themselves MSPs with their own clients). The company model is flat.
• Massive scale — thousands of companies and millions of tickets in one install.
• Enterprise procurement staples like SCIM auto-deprovisioning, tamper-evident audit with legal hold and multi-year retention, or contractual 99.99 % multi-region uptime.

The tell is always a requirement about isolation, assurance, certification, or guaranteed scale rather than what the tool does for a user. When you see that shape, the honest answer is "we're not the right fit" — and that's what keeps FreeITSM lean for everyone it is right for.

Known gaps we may improve

These are real, but solvable, and on the radar rather than ruled out:

• Clients without their own email domain (everyone on free email). Today the workaround is a pinned mailbox per such client; routing by individual sender address is a possible future option.
• Cross-company collaboration — a single ticket or asset shared between two clients isn't possible under strict isolation.
• Per-client branded portals on the client's own web address — possible later as a white-label feature; not required for the core experience.

See Pitfalls and the Worked Examples for how these play out in practice.