Domain separation and Customer Service Management

  • Release version: Zurich
  • Updated July 31, 2025
  • 4 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Domain separation and Customer Service Management

    Domain separation in Customer Service Management (CSM) enables ServiceNow customers to logically separate data, processes, and administrative tasks into distinct domains. This separation helps ensure that data is properly segmented and controlled according to tenant or organizational boundaries, improving security and data governance in multi-tenant or hybrid environments.

    Show full answer Show less

    CSM customers can grant access to contacts or consumers not only for cases but also for other entities such as problems, changes, and projects. Managed service providers (MSPs) can use domain separation to support multiple customers securely, each within their own domain, whether for service operations or billing and contract renewal support. Additionally, MSPs offering CSM as a service to their customers can leverage domain separation to maintain data isolation across customers.

    How Domain Separation Works in CSM

    Each customer account in CSM is aligned with a single domain. All related entities — including contacts, cases, addresses, assets, and others — reside in the same domain as the account. When a new account is created, the system automatically creates a domain with the same name and assigns the account and its related records to that domain. This ensures consistent data segregation and visibility controls within the application.

    Setup and Configuration

    • Activating domain separation requires the domain separation plugin, which customers must request from ServiceNow.
    • The csmautoaccountdomaingeneration property must be enabled to automatically create a domain matching each new account. This property is available only after activating the domain separation plugin.
    • Enabling this property affects only new accounts; existing accounts require a migration script available through ServiceNow Professional Services.
    • The Account [customeraccount] table is extended with Domain and Domain Path fields to support domain assignment and visibility, which can be customized for display.

    Implications for Data and Access

    • Related entities created for an account inherit the domain of that account, maintaining data separation across contacts, cases, assets, contracts, entitlements, addresses, social profiles, escalations, and product-related records.
    • Changing an account’s domain updates the domain assignment for all its related entities.
    • Customer service agents and managers require explicit assignment to the TOP/MSP/Default domain for visibility into cases and accounts.
    • Escalation templates and severity records are domain-separated, created by default in the global domain but configurable per domain as needed.
    • Ribbon configuration, Lookup and Verify settings, and Special Handling Notes support domain separation through process-separated table mechanisms, ensuring consistent domain-scoped data management.

    Additional Data Visibility Controls

    CSM supports enhanced visibility and access control through contact, partner, and parent-child entity relationships within domain separation, providing granular control over who can see and interact with data across domains.

    Domain separation is supported in Customer Service Management. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can 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. The domain separation includes 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.

    Sample use case: When a service provider (SP) uses chat to respond to a tenant-customer’s message, the customer must be able to see the SP's response.

    For more information on support levels, see Application support for domain separation.

    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. Administrators can synchronize the CSM account model with the domain structure and maintain data separation for entities that don’t 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 doesn’t add domains for existing accounts. It only creates domains for newly created accounts. Adding domains for existing accounts requires a migration script. You can request for the migration script from the ServiceNow Professional Services team.

    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 aren’t 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 can’t see case or account details until they’re 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’s created in the account domain.

    Domain separation for ribbon configuration, Lookup and Verify configuration, and Special Handling Notes

    Ribbon and Lookup Verify configurations and Special Handling Notes support domain separation as process-separated tables.

    When inserting or updating a record for process-separated tables, the picker domain scope takes precedence by design with the Overrides [sys_override] field on process-separated tables. For more information, see Process administration.