Domain separation and SRM

  • Release version: Yokohama
  • Updated January 30, 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 SRM

    Domain separation is supported in the Service Reliability Management (SRM) application, enabling data segregation across multiple tenants or domains within a single ServiceNow instance. This ensures that data, user interface elements, cache keys, reporting, and aggregations operate within the correct domain context during production runtime. Domain separation is implemented in all metadata and instance-level tables, with some internal tables separated implicitly. However, system properties remain shared at the instance level and are not domain-separated, which affects certain Team Management features.

    Show full answer Show less

    Key Features

    • The SRM application supports domain separation at a Basic level, meaning it works with some exceptions, particularly around team management.
    • Team creation and management are controlled through Integration Hub flows and catalog items, which must be customized by the customer to fully support domain separation.
    • Only one catalog item and flow can be configured per instance to create teams, and the requestor’s domain is captured as part of the team request item to maintain domain context.
    • The Service Operations Workspace and SRM workspace provide interfaces for administrators, managers, and responders to manage teams within domains.
    • When leveraging other applications, such as Event Management Connectors, domain separation capabilities depend on those applications’ support.

    Practical Implications for ServiceNow Customers

    • Customers must customize Integration Hub flows and team properties to ensure proper domain separation in SRM team management.
    • Because system properties are not domain-separated, some settings apply globally across domains, which can affect multi-tenant configurations.
    • For service providers (SPs), domain separation allows clear data segregation so that responses (e.g., chat communications) are visible only within the correct tenant context.
    • Understanding the domain separation scope and limitations in SRM is critical for correctly configuring multi-tenant environments and ensuring data privacy and operational integrity.

    Domain separation is supported for Service Reliability Management (SRM).

    Support level: Basic*

    The support level is Basic but has some exceptions or special conditions.

    • Business logic: Ensure that data goes into the proper domain for the application’s service provider (SP) use cases.
    • The user interface, cache keys, reporting, rollups, and aggregations all use the domain at production run time.
    • The owner of the instance must be able to set up the application to function across multiple tenants.

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

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

    Overview of domain separation

    • Domain separation is present in all metadata tables in the application. Instance level tables also have domain separation explicitly. Other internal tables, such as the internal Team Request table, are domain-separated implicitly by referencing domain-separated records.
    • System properties are not domain-separated, which has implications for Team Management features. The properties are shared by multiple domains and are set at the instance level. Domain-specific setup for these is not supported.
    • Where another application is being leveraged (for example the Event Management Connectors) domain separation is determined by the domain-separation capabilities of that application.

    How domain separation works in the Service Reliability Management application

    The specific conditions indicated by the Basic* support level rating above relate to team management:
    • New teams created through a catalog item backed by an Integration Hub flow are setup by the Service Operations Workspace administrator. They can initiate it from the Service Portal. An SRM admin, manager or responder can do it through the SRM workspace. Instructions appear in the SRM documentation.
    • Integration Hub subflows and actions control management of SRM teams.
    • Only one catalog item and flow can be set up for each instance. The customer is responsible for setting up team properties to support domain separation as a customization of the existing flows.
    • The requestor of a team catalog item is associated with the domain and is available as part of the request item. As a result, if needed, the requester can create the team in a specific domain or the catalog Item and extend it to capture the domain another way. In either case, the Service Operations Workspace must make changes to the Integration Hub flows and actions to support this.

    For more information, see Domain separation and On-Call Scheduling.