Domain separation and Operational Sustainability Management

  • Release version: Australia
  • Updated March 12, 2026
  • 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 Operational Sustainability Management

    Domain separation in Operational Sustainability Management allows ServiceNow customers to logically segregate data, processes, and administrative tasks into multiple domains. This capability ensures data segregation, delegated administration, and the ability to maintain global processes and reporting within a single instance. Users can control access by assigning domain visibility, enabling selective data access across different business entities or tenants.

    Show full answer Show less

    Although data separation is fully supported, separation of business logic and processes is limited. The application’s domain separation covers user interface, caching, reporting, rollups, and aggregations, supporting multi-tenant use cases primarily for service providers.

    How Domain Separation Works in Operational Sustainability Management

    Operational Sustainability Management enforces domain separation by associating records to the creator’s domain. Users must create and manage records such as goals, material topics, and targets in the appropriate domain to ensure proper visibility and usage across domains.

    For example, global-level goals can be accessed by all domains, whereas goals created in a specific domain are restricted to that domain and cannot be shared across others. Assignments from higher domains to lower domain users are not recommended because of access restrictions.

    Domain-Separated Tables

    The application domain separates multiple tables related to disclosures, goals, metrics, risks, controls, and material topics, among others. This separation ensures that operational sustainability data for different business areas or departments remains isolated, supporting secure multi-tenancy within a single instance.

    Practical Use Cases and Considerations

    • Operational sustainability data can be compartmentalized by department, allowing each to maintain its own goals, targets, and material topics without data leakage.
    • Users can toggle domain scope views to either isolate or aggregate information from specific domains.
    • Domain separation by default adds domain fields to core tables like Task and Configuration Items, and can be extended to custom tables by adding a domain field.
    • ServiceNow advises against domain separating platform-level tables (e.g., sysdictionary) as this may cause unexpected behavior.
    • Some global features and data, such as login options, remain shared across domains within the instance.
    • For complete isolation of all system properties and data, separate ServiceNow instances are recommended instead of domain separation.

    Why This Matters for ServiceNow Customers

    Domain separation enables ServiceNow customers using Operational Sustainability Management to securely manage multiple tenants or departments within a single instance while preserving data privacy and tailored administrative control. It supports service providers and complex organizations by facilitating multi-tenant operations, controlled data visibility, and consolidated reporting without cross-domain data exposure.

    Understanding domain separation helps ensure proper configuration and data governance, avoiding issues with data accessibility and process assignments across domains.

    Domain separation is supported for Operational Sustainability 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 domain separation

    Domain separation is useful for users who:
    • Enforce absolute data segregation between business entities (data separation).
    • Customize business process definitions and user interfaces for each domain (delegated administration).
    • Maintain global processes and global reporting in a single instance.
    These users can choose to expand or collapse the domain scope to show or hide data from other domains.
    Note:
    Users have access to data from domains that have been explicitly granted to them by domain visibility.

    How domain separation works in Operational Sustainability Management

    While Operational Sustainability Management supports separation of data, separation of logic and process is not fully supported. Many types of records in the Operational Sustainability Management application are automatically generated through user processes. Integrations with Project Portfolio Management and GRC: Metrics can create and associate data automatically. For records that are automatically and manually generated, the domain of the record is the same as the domain of the user responsible for creating or generating the records. Users must ensure that they are creating and generating records at the right domain level so that they are visible to the right set of users.

    For example, suppose you have domains that look like:
    • Global
    • TOP
      • Domain A
      • Domain B

    If you have operational sustainability goals, material topics and targets that you want to be assessed by users in domains A and B, the goals, material topics and targets should be manually created at the global level. If goals, material topics and targets are created in Domain B, you will not be able to use them in Domain A due to indexing.

    If you have operational sustainability goals, material topics and targets that you want to be assessed by users in Top and Domain A, you can create the risk or control in Domain A. Unless the goals, material topics and targets are in the Global domain, users must not assign risks or controls in a higher domain to users in a lower domain. In the example given, if you have a goal in the Top domain, you should not assign it to program manager in Domains A or B since those users would not have access to the this goal.

    Domain separated tables

    The following is the list of domain separated tables:
    • Disclosure
    • Disclosure Summary
    • Goal Activity Summary
    • Heatmap Chart Color
    • Composite Metric Definition to Citation
    • Composite Metric Definition to Goal
    • Composite Metric Definition to Target
    • Control to Goal
    • Control Objective to Goal
    • Citation to Disclosure
    • Metric to Disclosure
    • Metric Definition to Disclosure
    • Entity to Goal
    • Goal to Citation
    • Goal to Disclosure
    • Material Topic to Goal
    • Metric to Citation
    • Metric Definition to Citation
    • Metric Definition to Goal
    • Metric Definition to Target
    • Metric to Goal
    • Metric to Target
    • Policy to Goal
    • Risk to Goal
    • Risk Statement to Goal
    • Material Topic

    For more information on these tables, see Components installed with Operational Sustainability Management (formerly ESG Management).

    Use case

    Operational sustainability data can be separated from the data of other departments. Each business area using the Operational Sustainability Management application can have separate data that cannot be shared with other departments. Therefore, each department can have its own goals, targets, material topics, and so on. When looking at a goal from the operational sustainability domain, the user can choose to expand the domain scope to show values from the operational sustainability domain or collapse the domain scope to show only goals that match the operational sustainability domain. By default, domain separation adds a domain field to the Task [task]and Configuration Items [cmdb_ci] tables and their extensions. You can extend domain separation to any new tables you create by adding a sys_domain field to the table's dictionary definition. By default, the system only domain-separates platform and baseline application tables where appropriate.
    Note:
    ServiceNow® does not recommend domain separating platform tables such as any table with the sys_ prefix such as the Dictionary Entry [sys_dictionary] and Dictionary Entry Override [sys_dictionary_override] tables because it can produce unexpected results.
    In this use case, client scripts, business rules, workflows, processes, and so on can be domain-separated. While the behavior offered with domain separation provides multi-tenancy support, multi-tenancy is still contained within a single instance. This means that some global properties, some global data, and some global processes are shared across all domains. For example, the system’s “Remember me” option on the login page is global and cannot be specified per domain. If you need complete and total separation of all system properties and do not require global reporting or global processes, separate instances are the best option.