---
sourceDocument: Brazil IT Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/it-service-management

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# Domain separation and Change Management

# Domain separation and Change Management {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read  
Change Management supports domain separation. 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 {#domain-separation-change-mgt__section_ej3_cxq_xkb}

{#domain-separation-change-mgt__domain-sep-supported}  
* 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.
{#domain-separation-change-mgt__ul_yhr_g2j_xkb}

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.{#domain-separation-change-mgt__p_lsc_nfg_h1c}

For more information on support levels, see [Application support for domain
separation](https://www.servicenow.com/docs/access?context=domain-separated-apps&version=brazil&pubname=brazil-platform-security&ft:locale=en-US).{#domain-separation-change-mgt__p_msc_nfg_h1c}

## Domain separation in Change Management overview {#domain-separation-change-mgt__section_pvf_wkx_vcb}

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 {#domain-separation-change-mgt__section_ydt_kth_scb}

Change management involves the management of change requests. A change request enables 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.  
* The Change Request table extends the Task table. Records are created in the session domain of the user who creates the task.
* All change properties are global, meaning they are the same for every application that uses the System Property \[sys_properties\] table. This table isn't domain-separated, so any changes affect all domains.
{#domain-separation-change-mgt__ul_gcx_bk5_pdb}

Domain separated tables

Change Request \[change_request\].

Use case

A user with the itil role 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 {#domain-separation-change-mgt__section_dwm_q45_pdb}

* CAB meetings synchronize with the CAB Definition table if the meeting was generated from 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 in a different domain from the associated definition aren't supported.
* All other CAB records have their domain master set to the associated CAB Meeting record.
{#domain-separation-change-mgt__ul_jrb_s45_pdb}
Domain separated tables

* CAB Definition \[cab_definition\]
* CAB Meeting \[cab_meeting\]

{#domain-separation-change-mgt__ul_lh5_3p5_pdb} 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\]
{#domain-separation-change-mgt__ul_zbp_mp5_pdb}

Use cases  
* A CAB manager creates a new CAB definition and generates 20 meetings while in the ACME domain. 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.
{#domain-separation-change-mgt__ul_g5p_sp5_pdb}

## How domain separation works in Change Schedules {#domain-separation-change-mgt__section_ozv_xq5_pdb}

* 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-separation-change-mgt__ul_kjy_yq5_pdb}

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\]

{#domain-separation-change-mgt__ul_fbd_hr5_pdb}

Use cases

A user with the itil role 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 domain and the global domain.
**Related topics**   

* [Domain separation for service providers](https://www.servicenow.com/docs/access?context=domain-sep-landing-page&version=brazil&pubname=brazil-platform-security&ft:locale=en-US)