This is an overview of domain separation and Customer Service Management. With
domain separation you can separate data, processes, and administrative tasks into logical
groupings called domains. You can then control several aspects of this separation, including
which users can see and access data.
Support level: Basic
- Business logic: Ensure that data goes into the proper domain for the application’s
service provider use cases.
- The application supports domain separation at run time. This includes domain
separation from the user interface, cache keys, reporting, rollups, and aggregations.
- The owner of the instance must set up the application to function across multiple
tenants.
Use case: When a service provider (SP) uses chat to respond to a tenant-customer’s
message, the client must be able to see the SP's response.
Overview
Domain separation for Customer Service Management is designed for:
- Customers using the application in a domain-separated environment or in a
hybrid environment. With domain separation, a customer can grant access to
end users (contacts or consumers) to other entities in addition to customer service
cases. For example, contacts or consumers can access problems, changes, or projects.
System administrators can synchronize the CSM account model with the domain structure
and maintain data separation for entities that do not have account-based data separation
enabled.
- Managed service providers (MSPs) using the application to provide customer
support. In this scenario, an MSP can provide support to multiple
customers, where domains are necessary to contain all relevant customer data and
processes. For example, an MSP providing support to customers related to billing
questions, contract renewals, or other non-service operations.
- Managed service providers offering the application as a service that
customers can provide to their customers. In this scenario, an MSP can
offer Customer Service Management as a service to customers who, in turn, use the
application to support their end customers. This scenario requires additional
configuration due to domain support for some of the core entities in the platform such
as Product Model.
How domain separation works in Customer Service Management
Domain separation for Customer Service Management aligns each customer account to one domain.
To use domain separation with the application, all customer accounts must be assigned to a
domain.
The customer account is the main entity within Customer Service Management. All entities
related to the account, such as contacts and cases, are created in the same domain as the
account. This rule also applies for all entities on customer service cases, including
addresses, assets, and contacts.
When a new account is created, a domain of the same name is also created and assigned to the
account. All related entities for an account, such as contacts and cases, must reside in the
same domain. When a related entity for a domain separated account is created, the entity is
assigned to the account domain.
Setting up domain separation for Customer Service Management
Domain separation for Customer Service Management requires the domain separation plugin.
Contact ServiceNow to activate domain
separation.
Domain separation for Customer Service Management also requires enabling the
csm_auto_account_domain_generation property. This property is
installed with Customer Service Management and is available only after the domain separation
plugin is active. Contact ServiceNow to enable this property.
When the
csm_auto_account_domain_generation property is enabled, the
Customer Service Management application automatically creates a domain of the same name when a
new account is created.
Note: Enabling the
csm_auto_account_domain_generation property does not add domains for
existing accounts. It only creates domains for newly created accounts. Adding domains for
existing accounts requires a migration script.
Changes to Customer Service Management tables
Domain separation for Customer Service Management adds the Domain and
Domain Path fields to the Account [customer_account] table. These fields
are not exposed by default. Customers can customize lists and forms to view these fields.
Account domains and related entities
When creating related entities for an account, the domain for the related entities is set to
the account domain. Related entities include:
- Contacts
- Cases
- Assets
- Contracts
- Entitlements
- Addresses
- Social profiles
- Escalations
- Sold Products
- Installed Products
- Install Base Items
- Affected Install Base Items
- Sold Product Covered
Changing the domain for an account also changes the domain for all the account’s related
entities.
Domain visibility for customer service agents and managers
Users with the customer service agent (sn_customerservice_agent) and customer service manager
(sn_customerservice_manager) roles must be manually assigned to the
TOP/MSP/Default domain. Agents and managers cannot see case or
account details until they are assigned to the TOP domain.
Domain separation for case and account escalation
Escalation template records and escalation severity records are domain separated. By default,
these records reside in the global domain. Users can configure the Escalation Template and
Escalation Severity forms to display the Domain field and set the
domain as needed.
When an escalation record is created from a case or account, it is created in the account
domain.
