Domain separation and Change Management
Summarize
Summary of Domain separation and Change Management
Domain separation in Change Management allows ServiceNow customers to logically segregate data, processes, and administrative tasks into distinct domains. This separation controls user access and visibility, ensuring data is appropriately partitioned according to organizational or tenant boundaries. The Change Management application supports domain separation at runtime, covering user interface elements, caching, reporting, rollups, and aggregations. This capability is essential for multi-tenant environments, such as service providers managing multiple customers.
Show less
How Domain Separation Works in Change Management
Change Management organizes the lifecycle of change requests, which document detailed change information and enable controlled modification of configuration items (CIs). When users create change requests, the records are stored within their current domain session. However, global change properties stored in the sysproperties table are shared across all domains since this table is not domain separated.
Domain-separated tables include:
- Change Request [changerequest] – change requests are created in the user’s current domain.
How Domain Separation Works in Change Advisory Board (CAB) Workbench
CAB meetings and definitions are domain separated. Meetings generated from CAB definitions sync with the definition’s domain. Manually created meetings without a CAB definition are created in the user’s domain. Records linked to CAB meetings inherit the domain of the associated meeting.
Domain-separated tables include:
- CAB Definition [cabdefinition]
- CAB Meeting [cabmeeting]
- Domain tables linked to CAB Meeting’s domain: CAB Attendee, CAB Agenda Item, CAB Runtime State
Use case example: A CAB manager in the ACME domain creates a CAB definition and meetings, all of which reside in the ACME domain.
How Domain Separation Works in Change Schedules (New Feature)
Change Schedule definitions and related records are domain separated, created within the domain of the current user or the parent Change Schedule definition. This allows users to manage schedules relevant to their domain context.
Domain-separated tables include:
- Change Schedule Definition [chgsocdefinition]
- Related Definition [chgsocdefinitionchild]
- Style Rules [chgsocdefinitionstylerule, chgsocstylerule, chgsocdefchildstylerule]
Use case example: An ITIL user in the ACME domain can view Change Schedules applicable to their domain or globally.
Practical Implications for ServiceNow Customers
- Domain separation ensures secure and logical partitioning of change management data for multi-tenant or multi-department environments.
- Change requests, CAB meetings, and change schedules are created and managed within the user’s domain, preserving data integrity and access controls.
- Global properties affecting change management apply across all domains, which is important to consider when configuring system-wide settings.
- Service providers can use domain separation to manage multiple customers while ensuring each customer’s data and processes remain isolated and secure.
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.
- CAB Definition [cab_definition]
- CAB Meeting [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.