This is an overview of domain separation as it pertains to Vendor Risk Management (VRM)
and how it relates to VRM data separation. 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.
Domain separation is data only
Domain separation in this
application is supported at the Data only level, meaning it
supports the data security model of separating visibility of data from one domain to
another. 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, vendor data for Workday can be separated from the vendor data of
other vendors. Each vendor using the VRM application can have separate data that cannot be
shared with other vendors. Note: Users always have access to data from domains that have been
explicitly granted to them by domain visibility.
Use case: domain separation in Vendor Risk Management
Vendor data for Workday can be separated from the vendor data of other vendors. Each vendor
using the VRM application can have separate data that cannot be shared with other vendors. Each
vendor can have their own vendor contacts, vendor risk assessments, issues, tasks, and so
When looking at a vendor risk assessment from Workday domain, the user can choose to expand
the domain scope to show assessments from the Amazon domain or collapse the domain scope to show
only assessments that match the Workday domain.
By default, domain separation adds a domain field to the Task [task] and Configuration Items
[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) as this 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 a complete and total separation of all system properties is needed and does not require
global reporting or global processes, separate instances are the best option.
To learn more about domain separation, see Domain separation.