-
Notifications
You must be signed in to change notification settings - Fork 15
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.
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.
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.
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.
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.
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.
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).
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.
- 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.
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 (joe@gmail.com β 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.
FreeITSM β an open-source IT Service Management platform Β· github.com/edmozley/freeitsm Β· MIT licence
- Installation
- β° Scheduled tasks (cron jobs)
- Architecture
- AI Providers
- Internationalisation (i18n)
- Timezones & Time Handling
- Theming & Dark Mode
- β¨οΈ Command palette (βK)
- π Searching inside tickets
- π Attached documents
- MobileβFriendly
-
Security
- Layer 1 β which modules you can enter
- β³ π§© Module Access Control
- β³ π οΈ Module Access β Developer Guide
- Layer 2 β what you can administer
- β³ π Roles & Permissions
- β³ π οΈ Roles β Developer Guide
- β³ π€ Why capabilities are constants
- Layer 3 β the System module
- β³ π Admin Access Control
- Hardening
- β³ π Security review response 2026-08
- β³ π‘οΈ Security hardening 2026-08
- β³ π οΈ Security hardening 2026-08 β Developer Guide
- β³ π‘οΈ Round three β plain English
- β³ π οΈ Round three β Developer Guide
- Single Sign-On (SSO)
- ποΈ LDAP & Active Directory
- Browser Extension
- API Reference
-
π REST API β how it works
- β³ π« REST API: Tickets
- β³ π» REST API: Assets
- β³ π΄ REST API: Problems
- β³ π REST API: Changes
- β³ π REST API: Knowledge
- β³ β REST API: Tasks
- β³ ποΈ REST API: CMDB
- β³ π REST API: Contracts
- β³ ποΈ REST API: Calendar
- β³ πΏ REST API: Software
- β³ π¦ REST API: Service Status
- β³ βοΈ REST API: Morning Checks
- β³ π REST API: Forms
- β³ βοΈ REST API: Workflow
- β³ πΊοΈ REST API: Network Mapper
- β³ π§ Using the API docs page
- β³ π OpenAPI specification
- β³ β OpenAPI: kept correct
- β³ π οΈ Maintaining the catalogue
- Watchtower
-
Tickets
- β³ Mailbox Authentication
- β³ π€ Email send log
- β³ Basic IMAP mailboxes
- β³ Email rendering & images
- β³ SLA Management
- β³ WhatsApp channel
- β³ π¬ Web chat channel
- β³ π£ Slack channel
- β³ π Linking tickets
- β³ ποΈ Canned responses
- β³ βοΈ Limiting replies to particular senders
- β³ βοΈ Email signatures
- β³ π The public web address
- β³ π’ Ticket numbering
- β³ π Raising a ticket for someone else
- β³ π Merging tickets
- β³ β Splitting tickets
- β³ β Selecting several tickets
- β³ π οΈ Snoozing tickets β Developer Guide
- β³ π₯ Collision detection
- β³ β±οΈ Time tracking
- Problem Management
- Tasks
- Assets
- Knowledge
- Change Management
- Calendar
- Morning Checks
- Reporting
- Software
- Forms
- Contracts
- Service Status
- π Notifications
- π¨ War Room
- Self-Service Portal
- LMS
- Process Mapper
- CMDB
- Network Mapper
- Workflows
- Issue trackers (Jira, Azure DevOps)
- System
-
Overview
- β³ π Progress tracker
- β³ Concepts & vocabulary
- β³ Email routing & mailboxes
- β³ Settings: global vs per-company
- β³ Users & self-service
- β³ Staff cross-company access
- β³ Worked examples
- β³ Pitfalls & gotchas
- β³ Scope: what it's for
- β³ π οΈ Developer Guide (make a module multi-company)
- β³ ποΈ Case study: CMDB (a linked graph)
- β³ π§ͺ Test harness (prove it's isolated)