Multi Tenancy Settings

Multi-tenancy: settings — global vs per-company

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

Once you have more than one company, settings naturally split into two tiers. A single-company install never sees this split — the two tiers collapse into one flat Settings, exactly as today.

The two tiers

Global (install-level) — things you, the operator, control once; not a client's concern, often shared across all clients:

• Connected mailboxes (the email accounts + their authentication)
• AI provider keys, outbound mail, system configuration
• The list of companies itself
• Staff accounts and their cross-company access

Per-company — things that legitimately differ from client to client (reached by selecting the company in the company switcher):

• The company's email domains and reply identity
• SLAs and business hours
• Ticket categories, priorities, request types
• Branding
• Custom fields, forms, and knowledge-base publishing

The principle: no global "mode" switches

The most important rule in the whole design:

Wherever two organisations would want different behaviour, make it a property of the thing — or a global default with per-company overrides — never an install-wide "mode" toggle.

Mode toggles force everyone into a rigid either/or and create a second source of truth that drifts out of sync. Avoiding them is what lets one install accommodate wildly different organisations. You'll see the same trick three times:

• Mailboxes — pinned vs shared is a property of each mailbox, not an "MSP mode".
• Staff — which companies an analyst can see is a property of each analyst, so a "generalist" MSP and an "account-aligned" MSP both work with no switch.
• Shared config — global default + per-company override (below).

Shared config: global defaults + per-company overrides

For things whose global-vs-per-company nature is itself a matter of taste — categories, priorities, SLAs, workflows — FreeITSM won't ask you to flip a "global or per-company?" switch (changing that after you've created data is a nightmare). Instead:

• They're defined globally as sensible defaults.
• A company may override or extend them.

So an MSP that wants one standard taxonomy across every client simply never overrides — and it feels completely global. An MSP that wants each client bespoke overrides per company — and it feels completely per-company. One model, both worlds, and only one idea to learn.

Worked example: mailboxes

Mailboxes show the split neatly:

• Connecting and authenticating a mailbox is a global action — it's infrastructure, and a shared intake mailbox doesn't belong to any single client anyway. The only new choice on that screen is pinned (pick a company) or shared.
• A company's page owns only its genuinely company-specific bits — its domains and reply identity — and shows a plain-English, read-only summary like:

  "Mail arrives via the shared MyMSP intake (matched on acme.com, acme.co.uk) and a dedicated helpdesk-acme@themsp.com; replies are sent from helpdesk-acme@themsp.com."