This is an overview of domain separation and Change Management. Domain
separation allows you to separate data, processes, and administrative tasks into logical
groupings called domains. You can then control several aspects of this separation, including
which users can see and access data.
Support: Level 1
Domain separation is
supported in this application. Not all ServiceNow applications support domain
separation; some include limitations on the data and administrative settings that can be
domain separated. To learn more, see Application support for domain
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
- 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]
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.
- 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
Domain separated tables
CAB Definition [cab_definition]
- CAB Meeting [cab_meeting]
Domain master tables (linked to domain of its associated
CAB Attendee [cab_attendee]
- CAB Agenda Item [cab_agenda_item]
- CAB Runtime State [cab_runtime_state]
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.