-
Notifications
You must be signed in to change notification settings - Fork 15
Multi Tenancy Concepts
Part of the Multi-tenancy section. Planned / in design.
Getting a handful of words straight up front is what stops multi-tenancy getting confusing. Keep this page handy.
| Term | What it means |
|---|---|
| Tenant (a.k.a. company / client) | A separate client company. This is the isolation boundary β one tenant can never see another's data. Acme Ltd, Globex, "the biscuit factory". |
| Department | A team inside one company β IT, Finance, HR. A department is not a tenant; it lives within a company. |
| Analyst | A member of your support staff. Analysts can legitimately work across companies (handling Acme in the morning, Globex in the afternoon) β subject to permissions. |
| Requester | An end user who raises tickets (by email or via the self-service portal). |
| Mailbox | A connected email account that FreeITSM both reads from and sends as. A mailbox is the email identity of a company (or a department). |
This trips people up, so it's worth nailing:
- A company (tenant) is a separate organisation. Acme and Globex are two companies.
- A department is a team inside one organisation. Acme's IT team and Acme's Finance team are two departments of one company.
A common mistake is to reach for a new company when you really want a new department. Rule of thumb:
Different organisation β new company. Same organisation, different team β new department.
If a single business buys another business and wants their service desks kept apart, that's genuinely two companies. If a business simply adds its Finance team to the same service desk, that's a second department of one company.
The whole design hangs off the fact that the two groups of people behave differently:
- Analysts (your staff) are cross-company operators. They move between clients, and the interface gives them a company switcher and an "all companies" view for searching.
- Requesters (end users) are a single global identity whose individual tickets each belong to one company. One person, one login β but each ticket they raise is filed under the right client. See Users & self-service.
That asymmetry β staff roam, end-user tickets stay put β is why the staff and portal experiences are designed quite differently.
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
- β³ π 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)