ServiceNow Domain Separation 101

Here's in this article, I have put forth collection of best practices, conventional wisdom and answers to some questions, and this can be functional guide used along with ServiceNow Docs during planning & implementation of Domain Separation.

1- What is a Domain Separation??

ServiceNow's Domain Separation allows Service Providers to host more than one customer[tenant] on the single Instance - but they are separated virtually. Data & user experience is completed separated.

Example : Think of an Apartment - where each tenant have Flat or Unit separated by walls & door. With necessary safeguard, they enjoy personal space and they get to utilize common features or amenities - which the Apartment has to offer.

This is cost efficient way to host and manage more than one Customer, who may not have very large user base on the single instance.?

Notable Features

1. Data Separation: Tenants see only data that they have permissions to see. Tenants can be granted access to other tenant data, but cannot query tenant data if they don't have access.
2. Business Logic & UI Separation: Supports a tenant-specific experience for UI elements such as views, lists, labels, and so on. Similarly you can create tenant-specific system policies such as email notifications, business rules, client scripts, UI policy, and UI actions.
3. Hierarchical Modeling: Nested-multi-tenancy so parent tenants can access child tenant resources. Business logic for parent tenants runs automatically for child tenants, and can be overridden at any level.

?2- Where Domain Separation works & where it may not?

3- What questions do I ask before starting on this journey ?

• Consider organization-specific needs

If you have a high volume of automation and transactions, performance may make it impossible to host them on a single-instance.

• Customer spread across different geographies

If there is a need to support multiple regions as a global business system - data center location is important.

• Who is the Fulfiller? - MSP or customer?

Domain Separation prevents fulfillers from viewing data from other domains - self-service users can view only their own data

• Do customer business requirements require a specific ServiceNow configuration?

It is necessary to confirm whether it can be easily handled by domain hierarchy and process separation.

• Require physical separation of data due to regulations?

Physical separated architecture would be recommended than Logical

4. What is Data Separation vs Process Separation ?

• Data Separation

You can separate the data hosted in the same table by using "Domain[sys_domain]" column. This field will be available on almost all OOB Tables. When an end user logs in under a domain and pulls up a domain-separated table, ServiceNow uses built-in queries to pull data only from that domain.?

It is possible to enable this on an Custom Table as well by simply creating a field with name "sys_domain".

?

• Process Separation

By default, Domain will inherit Business logic & UI from its Parent or TOP. If required, you can customize both Business Logic & UI only for a given Domain which be can be enabled through "sys_overrides".

?

Caution : These Tables are NOT process separated by design.

• 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.
• Email Templates - These are globally reusable and not domain separated, but they are only invoked by Notifications, which are separated.
• Inbound Email - 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.

5. How to allow one child Domain's Users to see and/or modify Data of another child Domain ?

• Contains domains[domain_contains]

This table allows users of a domain "the containing domain" to see data from another domain "the contained domain". This applies to Data ONLY.?

This can be done other-way-around to allow circular accessibility, where Two Domain can see each other's data.

?

• User Visibility & Group Visibility

This Allows Specific Users or Groups to view data from a different Domain - which couldn't access otherwise. Granting users a visibility domain grants all the rights they would normally have to the record based on ACL (access control list) rule permissions.

6. How does other ServiceNow Features works along with Domain Separation ??

• SSO

Using the Multi-Tenant SSO Plugin, each tenant on an instance can have their own login strategy defined which might include separate identity providers (IdP's), or entirely different authentication methods per domain, both local and external (e.g. Digest, SAML 2, Local, LDAP, and others).

?

• Service Catalog

It can be difficult to share a defined catalog item across select items in the hierarchy without exposing it to an entire branch of domains.

?To address this, the catalog item can be made global so it can be reused across domains, and Instead leverage User Criteria to control which domains the item is available for.

• Workflows

Workflows are primarily defined in two tables, Workflow (wf_workflow), and Workflow Version (wf_workflow_version). Both the Domain & Overrides fields are available in Workflow table and not in the WF Version table - because records in that table point to a domain-separated workflow record.

So, to see which workflows are positioned as process overrides, you can simply add the domain and sys_overrides fields to the wf_workflow list.

Caution : Workflows execute in the domain of the user who initiated the record, not the domain of the workflow definition.

• Integrations?

Integration reads and move the data to different systems or fetch and populate the data. A simple way to control which Integration reads or update data in which Domain, is by having the integration run under a service account that resides in that domain.

• Update Sets

Update sets are global, but the payloads in the individual records of an update set may belong to a domain. Because of this, the domain picker must be set to global to commit an update set to an instance. This is meant as a safety net, preventing any kind of ambiguity when you apply an Update Set.

7. How can I optimize Domain Separation Configuration for better Platform Performance ?

• Default Domain

Organizing your domains is a crucial part of the domain separation process. If you don't set a default domain, new tasks and user records go to the global domain. Anyone can see the records in the global domain, which means that data can be seen when it is not supposed to.

?

• Contains and User/Group Visibility

Manage and avoid having too many domain contains and domain-visibility set up on the instance. Using a large number of domain contains/visibility generates queries with too many OR conditions, which are slow and impact performance.

?

• Hierarchy Changes

Minimize changes to the existing domain hierarchy. When the Parent is changed from A to B, the system will perform re-parenting of all the related domains that change the domain hierarchy. When the domain hierarchy is updated, the system triggers a cascade update on all domain aware tables for the records created on that domain. The number of queries the system has to run to change the domain hierarchy may severely affect performance.?

Wrapping up

Domain Separation helps enterprises optimize their costs and performance with multi-tenancy support in a single ServiceNow instance. If you would like to isolate data and processes across multiple business, you can quickly realize the benefits from domain separation. Like any other technical solution, domain separation have its advantages and drawbacks.