Tenants

The platform is **multi-tenant**: a single deployment hosts many **organisations** (tenants), each with isolated data, branding, and users. This is how MSPs run the platform once and serve many customers on it.

Mitch Wigham

Updated 24 June 2026 · 5 views

19 · Tenants

The platform is multi-tenant: a single deployment hosts many organisations (tenants), each with isolated data, branding, and users. This is how MSPs run the platform once and serve many customers on it.

Where to find it

/admin/tenants. Requires an ADMIN or SUPER_ADMIN role.

Concepts

Tenant / organisation — a logical container for data. Each tenant has its own users, customers, tickets, projects, devices, branding, licence features.
Admin tenancy — a special tenant flagged isAdminTenant=true that acts as the root. Users in the admin tenancy can manage other tenants. Usually 1 per install.
Membership — a (user, tenant) pair with a role. A user can have memberships in many tenants.
Shadow membership — when a user from the admin tenancy is given cross-tenant operator access. Doesn't appear in the target tenant's user list, but does have access to the data.

Layout

The page is a single table of every tenant, with the current tenant badged YOU ARE HERE and the admin tenancy badged ADMIN TENANCY. There are no status filters — every tenant is listed.

+----------------------------------------------------------+
| Tenants in use: 3 / ∞                                    |
|----------------------------------------------------------|
| Name                       Slug      Created             |
| KW Group  [YOU ARE HERE] [ADMIN TENANCY]  kwg   01/01/26  |
| Acme Ltd                              acme   14/03/26     |
| Beta Co                               beta   02/04/26     |
|----------------------------------------------------------|
| [ Tenant name ____ ]  [ Slug ____ ]      [ Add tenant ]   |
+----------------------------------------------------------+

📷 Screenshot placeholder: screenshots/tenants-list.png

Creating a tenant

The create form is an inline row at the bottom of the tenants table (shown only when the multi-tenant feature is enabled). It has just two fields:

Tenant name — the human-readable display name.
Slug — URL-safe (lowercase letters, digits and dashes only); used for storage keys and audit references.

Click Add tenant.

What happens automatically on create:

The new Organisation row is created.
Every active user whose primary org is the admin tenancy is given a shadow membership in the new tenant — so MSP staff can switch into the new tenant immediately without a per-tenant invite, but they don't appear in the new tenant's user list (the customer's admin doesn't see your team in their staff directory).

Features are not chosen during creation — a new tenant inherits every feature your licence covers until you set a per-tenant override (see below). Tenant creation does not seed SLA policies, ticket types, or project types, and it does not issue a separate per-tenant licence; the licence is platform-wide.

Per-tenant features

Tenant: Acme Ltd
+------------------------------------------------+
| Features                            [Save]     |
|------------------------------------------------|
| ☑ Helpdesk         ☑ CRM                       |
| ☑ Projects         ☐ RMM                       |
| ☑ KB              ☐ E-Sign                     |
| ☑ Marketing        ☑ Assets                    |
| ☐ Vault           ☐ Meetings                   |
+------------------------------------------------+

📷 Screenshot placeholder: screenshots/tenant-features.png

Toggle features on/off per tenant. Disabling a feature hides it from sidebars but does not delete data — re-enabling restores access.

⚠️ Caution. The set of features available is bounded by your licence. If a feature is greyed out, contact your licence provider or extend the licence under Licence.

Switching tenants

In the top bar, the tenant switcher dropdown lists every tenant you have a membership in (including shadow). Pick one to switch.

Your URL stays the same; the page reloads so per-tenant data refetches against the new orgId.
A user's default (landing) tenant is set by an administrator on the user's edit page under Tenant memberships. See Users & access.

🔒 Permissions. Two different rules apply:

The Admin → Tenants page is reachable by any ADMIN or SUPER_ADMIN. (The create form within it only appears when the multi-tenant feature is enabled.)
The top-bar tenant switcher is shown only to users with the SUPER_ADMIN role or a membership in the admin tenancy, and only when they belong to two or more tenants.

⚠️ Behind the scenes. The active tenancy lives in the JWT, not the user's database row. The portal calls /api/auth/me after every switch and re-reads orgId from the JWT, so the switcher chip and all UI scoping update immediately. If you ever see the chip stuck on the previous tenant, hard-refresh — that's a stale tab still holding a token issued before a service restart.

Inviting users into a tenant

Users are not invited from a tenant detail page — there isn't one. Invite a user from Admin → Users → Invite user; when the multi-tenant feature is enabled the invite form has a Tenant dropdown to pick which tenant the new account belongs to. See Users & access.

The platform's roles are SUPER_ADMIN, ADMIN, MANAGER, AGENT, CUSTOMER, and VENDOR.

Designating the admin tenancy

Any tenant can be made the admin tenancy. On the row you want, click Make admin tenancy and confirm. From then on, members of that tenancy are auto-granted shadow memberships in every newly-created tenant (existing tenants are unaffected).

Deleting a tenant

⚠️⚠️ Caution. Deleting a tenant cascades — every ticket, project, customer, contact, KB article, asset, device, file, and audit entry scoped to that tenant is permanently destroyed. There is no undo.

On the tenant's row, click Delete…. (The button is shown only to ADMIN/SUPER_ADMIN, never for the tenant you're currently in, and never for the admin tenancy itself.)
A confirmation modal asks you to type the tenant's slug.
On confirm, the delete runs immediately and reports how many rows were wiped and how many users were reassigned or deleted.

Users who only belonged to the deleted tenant are themselves deleted; users with other memberships have this tenant removed and (if it was their primary org) are repointed to one of their remaining tenants. Object-storage files are left as orphans for the platform's sweep job to clean up.

There is no archive / soft-delete option — deletion is the only removal path. To stop a tenant being used without destroying its data, disable all of its features instead (see Per-tenant features above).

Licence and per-tenant features

The licence is platform-wide, not per-tenant. A new tenant starts with every feature the licence covers; the per-tenant Features… override lets you narrow that down for an individual tenant. If the licence is renewed externally, the platform picks the change up — see Licence.

Common workflows

Onboard a new customer

Add a tenant — name + slug (e.g. acme).
Open Features… and trim it to what the customer bought.
Invite their admin from Admin → Users → Invite user, picking the new tenant in the form.
Switch into the new tenant and apply their branding via Studio.

Disable a customer who hasn't paid

Tenant → Features… → uncheck everything. They can still log in but every module is hidden. There is no separate suspend/archive control.

Permanently remove a tenant

Tenant row → Delete… → type the slug to confirm. The wipe is immediate and irreversible.