Features and Settings

Overview

Managed Service Provider (MSP) support allows a single platform tenant to serve multiple client organizations — referred to as Customers — from one unified instance, while keeping each Customer's users, tickets, teams, and configuration properly separated.

Instead of provisioning a completely separate platform instance for every client, an MSP-enabled tenant can:

• Onboard multiple Customers under one tenant
• Automatically identify which Customer a user or ticket belongs to, based on email domain
• Keep each Customer's users, tickets, groups, service teams, attributes, and audit history isolated from other Customers
• Apply Customer-specific configuration such as SLA targets, Service Portal branding, and enabled ticket routing queues
• Give tenant administrators centralized oversight across all Customers, while giving each Customer's own users visibility limited to their own organization

This is intended for organizations that deliver IT or business services to multiple external client companies from a shared platform tenant — for example, an MSP supporting several client accounts, each with its own users, domains, and service expectations.

Key Concepts

Concept	Description
MSP Tenant	A platform tenant with MSP mode enabled, capable of hosting multiple Customers.
Customer	A distinct client organization configured within an MSP tenant. Functions as its own workspace with its own users, groups, attributes, audiences, audit logs, service teams, and enabled modules.
Customer Domain	One or more email domains associated with a Customer (e.g., abccorp.com, abccorp.in) used to automatically identify which Customer a user belongs to.
Default Customer	A Customer designated to automatically receive users whose email domain is a recognized public/consumer domain (e.g., gmail.com) that isn't mapped to any specific Customer. Any Customer can be designated as the Default Customer, and this can be changed at any time.
Customer User	A Customer-level role. Can access the Service Portal and view only their own tickets.
Customer Executive	A Customer-level role. Can access the Service Portal and view all tickets raised within their own Customer.
Ticket User	A general-purpose role (not tied to a specific Customer) that allows a person to submit tickets. Can be held alongside a Customer-level role.
Bot User	A general-purpose role (not tied to a specific Customer) used for automated/bot accounts that submit tickets on a user's behalf (e.g., via chat/collaboration channels).
MSP Administrator (Tenant Admin)	A tenant-level administrator with visibility and management access across all Customers.
Service Team	A Customer-specific team (e.g., IT, HR) used to organize ticket routing.
Queue	A routing category within a Service Team (e.g., "Hardware" and "Software" under an IT team). Queues can be turned on or off per Customer; only the queues enabled for a Customer appear on the Agent UI for that Customer's tickets.
Customer Group	A group defined within a Customer, made up of an Owner and Members. Only Customer-level roles (Customer User, Customer Executive) can be added to a Customer Group.
Customer Attribute	A custom field defined for a specific Customer (e.g., "Entitlement" = Premium/Standard). Can be used in form fields and conditions, in Customer-specific audiences, and on user records within that Customer.
Tenant Attribute	A custom field defined at the tenant level, usable in tenant-level audiences that can reference a specific Customer and one of that Customer's attribute values.
Audience	A rule-based segment — Customer-specific or tenant-level — used to control the visibility of Service Catalog fields or offers on the Agent UI.
Service Portal	The self-service portal used by Customer-facing roles. Look and feel can be configured independently per Customer.

Architecture

MSP Tenant
 └─ Customers (e.g., ABC Corporation, XYZ Corporation, Default Customer)
     ├─ Customer Domain(s) (e.g., abccorp.com, abccorp.in)
     ├─ Users (Customer User, Customer Executive)
     ├─ Groups (Owner + Members, Customer-level roles only)
     ├─ Service Teams
     │    └─ Queues (enabled/disabled per Customer)
     ├─ Customer Attributes & Audiences
     ├─ Service Portal Configuration
     └─ Tickets (associated with this Customer)

A user or ticket is always associated with, at most, one Customer at a time. Tenant-level users and administrators sit above the Customer layer and are not tied to any single Customer.

Setup Requirements

Prerequisites (one-time setup)

1. Under Tenant Settings, go to Module Redirection Collections and map Module: Org Administration with Module Version: Org Administration, then select Add. This activates the Org Administration user management framework that MSP mode relies on.
2. Turn on the MSP toggle in Tenant Settings.
3. Create your Customers (Name, Email Domain(s), Industry; Primary Contact optional).
4. Designate one Customer as the Default Customer.
5. For each Customer, turn on the modules they need (e.g., Ticketing) under Org Administration module settings.
6. Set up Service Teams and their Queues for each Customer, and enable the queues that should be available.
7. Optionally, configure Customer Attributes, Audiences, SLA rules, and Service Portal look-and-feel per Customer.

Day-to-Day Usage (ongoing)

• Onboarding new users (manually, via CSV, or automatically through email/Teams/Slack/Service Portal)
• Reassigning users and tickets between Customers as needed
• Managing Customer Groups, Attributes, and Audiences
• Monitoring tickets and reports by Customer or across the tenant, depending on role

Important Behavior / Rules

Scenario	Expected Behavior
User's domain is mapped to a specific Customer	User and their tickets are associated with that Customer
User's domain is a recognized public/consumer domain, not mapped to any Customer	User and their tickets are associated with the Default Customer
User's domain is the tenant's own organizational domain	User remains at tenant level; no Customer association
A Default Customer ticket/user is moved to a specific Customer	Only that user is reassigned; their domain is unchanged and not added to the new Customer's domain list; future domain-based mappings are unaffected
User added directly under a Customer	Can only be assigned Customer-level roles (Customer User, Customer Executive)
User added at tenant level	Can be assigned any role except the Customer-level roles
A Customer's module (e.g., Ticketing) is not turned on	That Customer's users cannot use that module
A Queue is disabled for a Customer	That Queue does not appear on the Agent UI for that Customer's tickets
More than one Service Portal configuration exists for a Customer	Only one can be active at a time; if none is active, the default configuration applies
Primary Contact is set for a Customer	Automatically granted Customer User and Customer Executive roles

Limitations

• Only one Service Portal configuration can be active per Customer at a time.
• Customer-level roles are currently limited to Customer User and Customer Executive.
• Automatic Customer identification for ticket creation currently covers the Service Portal, Email, Microsoft Teams, and Slack channels.
• Reassigning a user from the Default Customer to a specific Customer is an individual action and does not retroactively or automatically map their domain to that Customer.