Key Highlights
A managed services provider serving twelve clients should not run twelve ITSM systems.
Technicians manage requests from one Technician Portal, while each company's requesters see only their own data through their own portal URL.
One console for technicians, spanning all managed companies.
Single-console access to all client environments with no instance switching.
Each company's requesters see only their own tickets, knowledge base, and announcements.
Multi-channel intake (Technician Portal, Support Portal, and Email) feeds the same unified queue.
Each Support Portal carries its own URL and branding, so clients sign in to an experience that looks like theirs, not the MSP's.
Per-portal helpdesk name, logo, favicon, and light/dark theme colors.
Optional SSO-only sign-on enforcement, applied per company.
Platform-level SAML 2.0 single sign-on spanning four identity providers.
OneLogin, Okta, Azure AD, and 1Kosmos.
Associate the modules each client needs, with configuration defined per client rather than shared with all.
Associate Request, Problem, Change, Release, Asset, and Project per company.
Plus Reports, Dashboard, Automation, and Support Channels.
Company-specific custom fields, SLAs, workflows, and reports for each company.
Per-client extension and integration through the full REST API.
The API spans Request, Change, CMDB, Asset, and user management.
Company boundaries are enforced automatically, from how users are assigned to how companies are removed.
Domain-based routing auto-assigns users whose email matches a domain to the correct company.
LDAP/AD and SCIM provisioning keep each company's user directory in sync.
Deleting a company automatically deletes its associated Support Portal, leaving no orphaned client data.
Intelligence
The strain shows the moment a second client signs a different SLA. A platform built for one company offers one escalation path, field layout, approval chain, and SLA set. Serving two clients on that platform either forces the fast-moving client into slow governance or leaves the regulated client exposed.
Multi-Company ITSM separates clients cleanly enough to honor distinct contracts while operating from one console that technicians manage, eliminating instance switching. Onboarding becomes a configuration task: define the company, associate a branded portal, apply SSO-only enforcement where required, and start receiving requests. No new stack to provision.
How It Works
Enable Managed Services Provider mode in the license.
The Managed Services Provider option then appears under Admin > Organization.
Create a Company for each department or child company served.
Add company-specific detail with Companies Custom Fields on the create-company form.
Use the Domain setting so users whose email matches a domain auto-assign to the right company.
Create a Support Portal and associate it to the company, one portal per company.
Give it its own URL and optional SSO-only enforcement.
Brand it with helpdesk name, logo, favicon, and theme colors.
Federated SSO:Authenticate users through platform-level SAML 2.0 SSO spanning four identity providers (OneLogin, Okta, Azure AD, 1Kosmos). Identity is platform-level, not a separate IdP per company.
Add LDAP/AD and SCIM provisioning to keep the platform user directory in sync.
Each Support Portal serves its company's requesters their own requests, knowledge base, and announcements.
Technician portal:From the single Technician Portal, technicians work with all companies.
Define per-company SLAs, workflows, and reports.
Associate the company with the modules it needs: Request, Problem, Change, Release, Asset, and Project.
Plus Reports, Dashboard, Automation, and Support Channels.
Delete a company and its associated Support Portal is removed automatically.
Company boundaries stay clean as the client list changes.
Role-Based Value
Twelve clients do not need twelve ITSM systems because one platform carries as many branded, isolated company portals as there are clients.
Twelve clients do not need twelve ITSM systems because one platform carries as many branded, isolated company portals as there are clients.
Distinct contracts are honoured with per-client SLAs, workflows, fields, and reports. The platform stays unified.
Distinct contracts are honoured with per-client SLAs, workflows, fields, and reports. The platform stays unified.
Technicians manage all client requests from one Technician Portal while requesters see only their own company's data.
Technicians manage all client requests from one Technician Portal while requesters see only their own company's data.
Onboarding a client is a configuration step, not a deployment project: create a company, associate a portal, enforce their sign-on policy.
Onboarding a client is a configuration step, not a deployment project: create a company, associate a portal, enforce their sign-on policy.
From Visibility to Control
Scale to many clients on one instance, instead of patching a separate deployment for each.
Honor distinct contracts with per-client SLAs, workflows, fields, and reports. No platform fork required.
Give each client a portal that looks like theirs, with their own branding, URL, and sign-on.
Onboard new clients as a configuration step, not a fresh deployment project.
The step is: create a company, associate a portal, enforce their sign-on policy.
Lower total cost of ownership: one platform to license, host, upgrade, and administer for the book of business.
Explore More