Domain separation and Change Management

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

    Domain separation in Change Management allows ServiceNow customers to logically separate data, processes, and administrative tasks into distinct domains. This separation controls which users can view and access data, ensuring proper segmentation especially useful in multi-tenant or service provider environments. Change Management itself is designed to facilitate controlled, low-risk changes to IT services by managing change requests and related processes.

    Show full answer Show less

    Key Features

    • Domain Separation Support: Change Management supports domain separation at runtime, including UI, cache keys, reporting, and aggregations.
    • Change Requests: These are created within the user’s active domain and capture all essential change details such as reason, priority, risk, and category. Change request data is stored in the domain-separated changerequest table.
    • Global Properties: Some settings, stored in the non-domain-separated sysproperties table, apply globally across all domains.
    • Change Advisory Board (CAB) Workbench: CAB meetings and definitions are domain-aware. Meetings created via definitions reside in the same domain as the definition. Manually created meetings are assigned to the user’s domain. Related CAB records inherit the domain of their associated meeting.
    • Change Schedules (New Feature): Change Schedule definitions and related records are domain-separated, created in the current user’s domain or associated Change Schedule domain. Multiple style rule tables are domain-separated to support customization per domain.

    Practical Use Cases

    • An ITIL user creates a change request in their selected domain, ensuring data isolation and proper domain ownership.
    • A CAB manager creates CAB definitions and schedules meetings within a specific domain, maintaining domain consistency for CAB records.
    • Users can view Change Schedules filtered by their current or global domain, supporting domain-specific planning.
    • Service providers can use domain separation to manage tenant data securely and ensure that communications and changes are visible only to authorized domains.

    Why It Matters

    Domain separation in Change Management enables organizations and service providers to maintain data privacy, enforce access controls, and streamline IT change processes across multiple tenants or business units within a single ServiceNow instance. This approach reduces risk, enhances compliance, and supports multi-tenant scalability.

    What to Expect

    • Change requests and CAB records will be created and managed within their respective domains, preserving data segregation.
    • Some global properties affect all domains, so changes here impact the entire instance.
    • Administrators must configure domain separation properly to leverage these features across tenants.
    • Users will experience domain-specific views and processes aligned with their assigned domain context.

    Domain separation is supported in Change 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.

    Domain separation in Change Management overview

    Change Management provides a systematic approach to controlling the life cycle of all changes, facilitating beneficial changes with minimum disruption to IT services.

    How domain separation works in Change Management

    Change management involves the management of change requests. A change request allows you to implement a controlled process for the addition, modification, or removal of approved and supported configuration items (CIs). The request records the detailed information about the change, such as the reason for the change, the priority, the risk, the type of change, and the change category.

    • A change request is an extension of a Task. Records are created in the domain of users creating the task they have in session.
    • All change properties are global, meaning they are the same for every application that uses the [sys_properties]table properties. The table is not domain separated so any changes made impact all domains.

    Domain separated tables

    Change Request [change_request].

    Use case

    An ITIL user in the Acme domain logs in and creates a change request. The change request is created in the domain that the user has selected.

    How domain separation works in Change Advisory Board (CAB) Workbench

    • CAB meetings synchronize with the CAB Definition table if the meeting was generated via a definition, or the meeting was created manually and has the CAB Definition field populated.
    • CAB Meetings are created in the domain of the user if the meeting is created manually without an associated CAB definition.
    • Meeting records are not supported if in a different domain from the associated definition.
    • All other CAB records have their domain master set to the associated CAB Meeting record.
    Domain separated tables
    • CAB Definition [cab_definition]
    • CAB Meeting [cab_meeting]
    Domain tables (linked to domain of its associated cab_meeting)
    • CAB Attendee [cab_attendee]
    • CAB Agenda Item [cab_agenda_item]
    • CAB Runtime State [cab_runtime_state]

    Use cases

    • A CAB manager creates a new CAB definition and generates 20 meetings while in the ACME domain. The result: Both the definition and meetings are created within the ACME domain.

    • A CAB manager creates an ad-hoc CAB meeting from the related list on the CAB definition form. Result: The meeting is created in the domain of the CAB meeting.
    • All other use cases behave in the same way as when domain separation is not enabled.

    How domain separation works in Change Schedules (New feature)

    • Change Schedule definitions encapsulate all the configuration options and related records used to display a given Change Schedule.
    • Records are created in the domain of the current user.
    • Ancillary records are created in the domain of the Change Schedule definition.

    Domain separated tables

    • Change Schedule Definition [chg_soc_definition]
    • Related Definition [chg_soc_definition_child]
    • Style Rule [chg_soc_definition_style_rule]
    • Style Rule [chg_soc_style_rule]
    • Style Rule [chg_soc_def_child_style_rule]

    Use cases

    An ITIL user in the ACME domain logs in and navigates to the Change Schedule landing page. The user can view the Change Schedules in both their current or global domain.