Tips for Domain Separating 'NON Out of Box Domain separated' Tables - Support and Troubleshooting

Tips for Domain Separating 'NON Out of Box Domain separated' Tables Issue Background:

With the activation of the Domain Separation plugin, the system by defaults activates Domain Separation on many platform tables.

Here is online documentation about this:

Domain Separation

This is documented in the last 2 sections in the above link under 'Application support for domain separation' and 'Installed with Domain Separation sections'.

In addition, any custom table created on the instance or even many of the out-of-box tables can be customized and domain separated simply by adding the 'sys_domain' field to the table.

However, there are some tables/applications that should never be Domain separated, while some other tables/applications were just adding the sys_domain field is not adequate to achieve domain separation and therefore domain separating such tables is not recommended by ServiceNow.

This document attempts to detail this information.

Deny listed tables for Domain Separation

The sys_security_restricted_list table stores potential deny list and allow listed entries for platform tables.

Domain Separation tables that are deny listed have the Type field set to 'deny list' and List context field set to 'non_domain_separable' as per screenshot below.

Out of the box, when the Domain Separation plugin is activated, the system adds the above 5 tables as non_domain_separable: Security exclusive/inclusive list Entities, ACL, Dictionary, System Properties, and Script Includes.

Domain Separation on Specific Out of Box Tables

CMDB:

While CMDB shows as Level 2 support for Domain support, there are some considerations that should be taken when planning on implementing domain separation on the entire CMDB across the board. Some considerations are data volume, possible duplication of data, and whether the records are meant to be reference data common to all domains or whether they have domain-specific attributes. Domain separating the entire CMDB would impact all of the tables that reference or extend it. In addition, certain classes, identifiers, and CI relationship types are not domain-aware due to platform limitations.

CMDB Models :

CMDB Models are currently not domain separated out of the box. Domain separation for models would be an enhancement request that would need to be reviewed by our product owner. While the Cmdb_model table can be domain separated by customers since it is referenced by many other tables (such as Assets, Transfer Orders, Contracts, Catalog Items, etc). Domain separating cmdb_model would impact all of the tables that references it. Some considerations before domain separating CMDB Models are data volume, possible duplication of data, and whether the models are meant to be reference data common to all domains or whether they have domain-specific attributes.

IP Services:

Currently, IP Services is not domain aware out of the box and we have PRB1104438 for this which will be fixed in a future release.

CI Relations:

As per our online documentation, it is not recommended to domain separate CI Relations (cmdb_rel_ci) table and it does not have the sys_domain field out of the box. Instead, you can create a before Query user Business Rule. If the user's domain is the same as the company field of the parent in the cmdb_rel_ci table, then the user should be able to query the records where that condition is valid.

Field Encryption (com.glide.encryption Plugin):

Field Encryption should work with Domain Separation without any additional changes

Operational Intelligence:

Domain support is not currently available for Operational Intelligence, but it is currently planned for an upcoming release. Domain support will be for Data Only

Fiscal Calendars:

Domain support is not currently available for Fiscal Calendars, however, it is planned to be supported in a future release. ServiceNow does NOT recommend customizing Fiscal Calendars to make it domain-aware as the implementation is rather complex and requires a lot of changes.