DOMAIN 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 in different ways.
Domain separation is like a building of offices or apartments where tenants rent or lease individual spaces. Like this, Managed Service Providers, or MSPs, can lease portions of a ServiceNow instance to other businesses by using Domain Separation in ServiceNow. This implies that numerous clients can use a single instance. Multiple clients can live on the same instance when domain separation is enabled, which is like to different businesses renting space in the same office block. The instance has global attributes, data, and processes that are shared across all domains, just like an office has shared spaces and resources.
Domain separation is enabled by the paid plugin Domain Support - Domain Extensions Installer.
Just as a tenant in a leased building enjoys exclusive use of their space, each domain in a ServiceNow instance can maintain its own set of data that remains hidden from other domains. This is achieved through data separation.
Similarly, each domain can implement unique functions and processes—such as customised business rules—and even feature a distinct user interface tailored to its needs. This level of domain-specific customisation is made possible through process separation.
Domain Hierarchy
A domain hierarchy is a structure of domains within an instance that establishes parent/child relationships, which in turn determine the scope of processes and data visibility. These relationships are defined in the domain table using the parent field
TOP is the root domain in the hierarchy. It contains only process records that define universal, instance-wide processes and platform elements.
Customer domains store data and process settings unique to each customer. They can also include customer-specific UI settings.
Some customers set up a dedicated domain for an MSP company to manage internal business data such as tasks, users, and CIs.
ServiceNow recommends having one Default domain in each instance.
The Default domain can be placed anywhere in the hierarchy. It acts as a failsafe measure to prevent records from accidentally being created as globally visible. The Default domain serves as a "holding area" for records that have not yet been assigned a domain.
It can also help identify processes that are incorrectly creating global records.
All new instances come with a Default domain, and sensitive records (such as tasks, users, and companies) are placed there by business rules.
There can be only one Default domain, and it must be located in an area accessible only to instance owners and not to customers. If no Default domain is set, new unassigned records are placed in the Global domain.
Data Separation
Data separation is enforced at the database level through the use of the sys_domain column in tables. About 2,000 base platform tables already have this column, making them “domain-separated”. To make a custom table domain-separated, you can add the sys_domain field to the table.
When a customer logs in under a particular domain and accesses a domain-separated table, the system uses built-in queries to pull data only from that domain and its children.
When data separation is enabled, data from child domains will be visible from their parent domains.
Users working within a domain do not have access to:
Data in their parent domains.
Data in peer domains.
Domains in other branches of the hierarchy.
In the example above, TOP is a Service Provider. It has two customers: Proxima, which has three child domains, and Cloud Dimensions, which has one child domain. Because TOP is at the top of the hierarchy, it can see data for both Proxima and its customers, as well as data from Cloud Dimensions and its sole customer.
Proxima can view data for all three of its child companies; however, users in the Proxima Resorts, Proxima Cruises and Proxima Residences domains can only see data within their own domains since they are at the bottom of the hierarchy.
Users working in the top domain in the hierarchy can see data in the entire instance.
Separated and Non Separated Tables
Separated Tables: In the system dictionary, you'll see tables that include the sys_domain column. These tables are data-separated and considered domain-aware. You can also view these dictionary records using the "Domain Admin/Domain Separated Tables" module.
Non Separated Tables: Some tables and applications should never be domain-separated. For others, simply adding the sys_domain field isn’t enough to achieve domain separation, so it’s not recommended. When the domain separation plugin is activated, the system marks certain tables—like ACLs, Dictionary Entries, System Properties, Email Templates
(These are also globally reusable and not domain separated, but they are only invoked by Notifications, which are separated), Inbound Email(Inbound Email Actions are not domain separated, as their conditions are first evaluated before there is an awareness of who the user and current record are. They can be made domain aware through scripting) and Script Includes (These are intended to hold global, reusable scripts but are not domain separated. Script Includes are called from Business Rules, which are separated.)—as non-domain-separable.
Detailed information on domain-separating non-out-of-box tables and the exclusion list tables is available here:
Tips for Domain Separating 'NON Out of Box Domain separated' Tables
Process Separation (Delegated Administration)
Processes can also be separated by domain. This is achieved by using the sys_overrides column in domain-aware tables. Any table that includes both the sys_domain and sys_overrides fields can be configured to run processes differently from the parent domain. For example, you could have a business rule defined in the Top domain and then override it in a child domain so that a different rule applies there. Similarly, two users signing into different domains might see different user interfaces.
If only data separation is activated without process separation, all domains will use the same business rules. Alternatively, you can choose to separate processes without separating data.
System policy functions such as Assignment Rules, Approval Rules, SLA Management, Inactivity Monitors, Email Notifications, Business Rules, Client Scripts, UI Policies and UI Actions can be defined globally or specifically for a particular domain. Since the platform is expanding and new applications are being added, this is just a partial, growing list.
Forms, Lists, Related Lists, and Choice Lists can also be domain-specific. For example, if a particular domain requires different fields on a form, no problem! If a customer wants a different set of choices in a choice list, the list can be customized for their domain.
Service providers can even customize the branding and user interface elements for a domain.
Expanding Data Visibility
Domain hierarchy determines who can see which data. Sometimes, however, you might want customers to view data from a domain outside their hierarchy. You can expand data visibility in two ways: using Contains tables or Visibility tables. Additionally, a Default domain can restrict access to records that haven’t been assigned to any domain and would otherwise fall under TOP or global.
Domain containment:
The Contained Domains table (domain_contains) lets one domain include another. This means users in one domain can see data from another domain, even if it isn’t visible through the regular hierarchy. Note that this only affects data, not processes.
For example, if you want Proxima Resorts to view data from Proxima Cruises, you can have Proxima Resorts contain Proxima Cruises. You can even set up a circular containership so that two domains can see each other’s data.
The Proxima Resorts domain contains the Proxima Cruises domain allowing Proxima Resorts to view Proxima Cruises data.
Visibility tables:
Domain visibility tables (sys_user_visibility and sys_user_group_visibility) let you give specific users or groups permission to see data in domains they normally can’t access. For example, if someone in the Proxima Resorts domain needs access to data in the Proxima Cruises domain, you simply add that permission to their profile. Visibility rules can be used with contains relationships, or they can be used separately
