Domain separation and Customer Success Management

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 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 Success Management

    The Customer Success Management application supports domain separation, enabling you to logically separate data, processes, and administrative tasks into distinct domains. This separation controls user access and visibility, ensuring data integrity across multiple tenants or service providers within the same instance. Domain separation applies to key components such as onboarding cases, tasks, engagements, objectives, outcomes, and risk signals, all managed at the account domain level.

    Show full answer Show less

    Key Features

    • Domain Separation Support: Basic support allowing data segregation at runtime, including separation in the user interface, cache keys, reporting, rollups, and aggregations.
    • Account-Level Separation: Onboarding cases, tasks, engagements, objectives, initiatives, success cases, risk signals, and internal plays are all separated by account domain.
    • Data Import Considerations: Account onboarding and data import tasks are domain separated, though staging tables for data import are not.
    • Configuration Requirements: Requires enabling the domain separation plugin and activating the csmautoaccountdomaingeneration property for automatic domain generation.
    • Multi-Tenant Setup: Instance owners must configure the application to operate across multiple tenants, supporting use cases such as service providers interacting with tenant customers while maintaining data separation.

    Key Outcomes

    • Improved data security and access control by restricting data visibility and operations to specific domains/accounts.
    • Support for service providers managing multiple tenants within a single ServiceNow instance without data overlap or unauthorized access.
    • Consistent enforcement of domain boundaries across Customer Success Management workflows, reporting, and data aggregation.
    • Streamlined onboarding and success tracking processes segregated by account, enhancing operational clarity and customer management efficiency.

    Practical Considerations for ServiceNow Customers

    To leverage domain separation in Customer Success Management, ensure the required plugin and domain separation property are enabled. Plan your instance setup to define domains per tenant or customer account to maintain proper data isolation. Understand that while key tables are domain separated, some staging tables used during data imports are not, which may impact import processes. This setup is essential for service providers managing multiple customers to ensure secure, segregated data access and reliable customer success tracking.

    Domain separation is supported for Customer Success 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 of Customer Success Management

    With the Customer Success Management application, you can create onboarding cases and related onboarding case tasks, track objectives, outcomes, and define documented plans to ensure success. The account onboarding case and related tasks support domain separation at the account level. Engagements, objectives, outcomes, initiatives, success cases, risk signals and internal plays are domain separated at the account level.

    How domain separation works in Customer Success Management

    • Account onboarding cases, onboarding tasks, and data import case tasks are domain separated using the account domain.
    • All other staging tables used for the Data Import are not domain separated.
    • All customer success tables are domain separated.

    Setting up domain separation in Customer Success Management

    Domain separation for Customer Success Management requires the domain separation plugin and enabling the csm_auto_account_domain_generation domain separation property. For more information on setting up domain separation, see Domain separation and Customer Service Management.

    Domain separated tables

    • Account onboarding case [sn_acct_lc_onb_case]
    • Data import task [sn_ti_core_imp_task]
    • Onboarding task [sn_ti_core_task]
    • Engagement [sn_acct_lc_engagement]
    • Success objective [sn_acct_lc_success_objective]
    • Success outcome [sn_acct_lc_success_outcome]
    • Success initiative [sn_acct_lc_success_initiative]
    • Customer play [sn_acct_lc_success_case]
    • Success task [sn_acct_lc_success_task]
    • Touchpoint [sn_acct_lc_touchpoint]
    • Internal play [sn_acct_lc_internal_play]
    • Internal play task [sn_acct_lc_internal_play_task
    • Risk Signal and Issue (sn_acct_lc_risk_signal_issue)
    • Implementation Record (sn_acct_lc_implementation_record)
    • Risk Solution (sn_acct_lc_risk_signal_solution_relationship)
    • Engagement Health Definition (sn_acct_lc_eng_hlt_def)
    • Health Metric Configuration (sn_acct_lc_eng_hlt_mtr_config)
    • Engagement Risk Definition (sn_acct_lc_eng_risk_def)
    • Risk Threshold Override (sn_acct_lc_risk_threshold_override)
    • Risk Occurrence (sn_acct_lc_risk_occurrence)
    • Data Source (sn_data_ctx_engine_src)
    • Context Engine Mapper (sn_data_ctx_engine_map)
    • Context (sn_data_ctx_engine_ctx)
    • Context Engine Data (sn_data_ctx_engine_data)
    • Segment (sn_data_ctx_engine_brkdwn_seg)
    • Segment Configuration (sn_data_ctx_engine_seg_conf)
    • DCE Insight (sn_data_ctx_engine_insight)
    • DCE Insight Item (sn_data_ctx_engine_insight_item)
    • DCE Visualization (sn_data_ctx_engine_visualization)
    • DCE Visualization M2M (sn_data_ctx_engine_visualization_m2m)
    • Product Capability (sn_prod_cap_core_prod_cap)
    • Product Capability Map (sn_prod_cap_core_prod_cap_map)
    • Capability Relationship Map (sn_prod_cap_core_cap_rel_map)
    • Product Usage (sn_prod_cap_core_prod_usage)
    • Product Capability Usage (sn_prod_cap_core_prod_cap_usage)