This is an overview of domain separation and Governance, Risk, and Compliance. Domain
separation enables 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
Domain separation is best for those customers who:
- Need to enforce absolute data segregation between business entities (data separation).
- Customize business process definitions and user interfaces for each domain (delegated
- Maintain some 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. For example, GRC data for IT can be separated from the GRC data from other departments.
Each business area using the GRC application has separate data that cannot be shared with other
Note: Users always have access to data from domains that have been explicitly granted to them by
How domain separation works in GRC
- While GRC supports separation of data, separation of logic and process is not fully
Many types of records in GRC are automatically generated through user processes. Profiles,
controls, risks, indicators, and control tests are all fields that can be generated
automatically. For records that are automatically generated (and for any GRC record that is
manually generated), the domain of the record is the same as the domain of the user
responsible for creating or generating the records.
Automatic generation should be kept in mind when working in a domain-separated GRC
implementation. Users should be sure that they are creating / 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:
- If you have a risk or control that you want to be assessed by users in domains A and B, the
risk or control should be generated or manually created at the global level. If the risk or
control is created in Domain B, you will not be able to recreate the risk or control in Domain
A due to indexing.
- If you have a risk or control 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 risks and controls are in the Global domain, users should not assign risks or
controls in a higher domain to users in a lower domain. In the example above, if you have a
control in the TOP domain, you should not assign it for attestation to users in Domains A or B
since those users would not have access to the control; thus the attestation or assessment
questionnaire would not be generated.
Similarly, users should not assign policy statements and risk statements in a higher domain to
attestations and assessments in a lower domain. Otherwise the attestation or assessment
questionnaire would not be generated.
GRC data for IT can be separated from the GRC data of other departments. Each business area
using the GRC application can have separate data that cannot be shared with other departments.
Therefore each department can have its own profiles, policies, controls, risks, and so on.
When looking at a control from the IT domain, the user can choose to expand the domain scope
to show values from the Finance domain or collapse the domain scope to show only controls that
match the IT domain.
By default, domain separation adds a domain field to the Task
[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.
Warning: ServiceNow does not recommend domain separating platform tables (any table
with the sys_ prefix such as the Dictionary Entry
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
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
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.