Domain Separation in ServiceNow: Understanding Multi-Tenant Data and Process Isolation

[JAGRUTHIK]

Introduction

In many organizations, a single ServiceNow instance is used by multiple customers, business units, or organizations. While sharing the same instance reduces the need to maintain multiple environments, it also creates an important requirement: different organizations must be able to work with their own data and processes without unintentionally accessing or affecting another organization's information.

This is where Domain Separation comes into play.

Domain Separation is a ServiceNow capability that allows data, business processes, and administrative responsibilities to be logically separated within a single ServiceNow instance. It is commonly used in environments where multiple tenants or organizations share the same platform.

What Is Domain Separation?

Domain Separation provides a way to partition a ServiceNow instance into logical domains.

For example:

Imagine a company uses a single ServiceNow instance to provide services to two different organizations: Organization A and Organization B.

Both organizations use the same ServiceNow platform, but their data needs to remain logically separated.

For example, Organization A may have its own incidents, requests, users, and configurations, while Organization B has its own incidents, requests, users, and configurations.

With Domain Separation, each organization can be assigned to a separate domain. When a user from Organization A works in ServiceNow, they operate within Domain A and generally see the data associated with that domain. Similarly, users from Organization B work within Domain B.

This allows both organizations to share the same ServiceNow instance while maintaining appropriate boundaries between their data and processes.

In simple terms:

One ServiceNow instance → Multiple domains → Each domain has its own users, data, and processes.

Each domain can have its own users, data, and domain-specific behavior while still operating within the same ServiceNow instance.

The exact level of separation depends on how the domain hierarchy and access relationships are designed.

Why Is Domain Separation Needed?

Consider a ServiceNow instance supporting two independent organizations:

Organization A

   ├── Incidents

   ├── Requests

   └── Knowledge

Organization B

   ├── Incidents

   ├── Requests

   └── Knowledge

Without appropriate separation, users from Organization A could potentially encounter records belonging to Organization B.

Domain Separation helps establish boundaries so that users work with the records and processes relevant to their domain.

This is particularly useful for:

• Managed Service Providers
• Service providers supporting multiple customers
• Enterprise organizations with independent business units
• Multi-tenant ServiceNow implementations
• Organizations requiring logical data isolation

Domain Hierarchy

One of the fundamental concepts in Domain Separation is the domain hierarchy.

A hierarchy can look like:

                      TOP

                         |

              Service Provider

                 /                 \

                /                    \

           Customer A     Customer B

A domain can have:

• A parent domain
• One or more child domains
• Domain-specific users
• Domain-specific data
• Domain-specific configurations

The hierarchy determines how data and processes can be inherited or accessed across domains.

Types of Domain Relationships

ServiceNow provides different ways of establishing relationships between domains.

The three concepts developers should understand are:

1. Parent and Child Domains

A parent-child relationship provides hierarchical inheritance.

Parent Domain

      |

      +---- Child Domain A

      |

      +---- Child Domain B

This relationship can affect both data and processes.

1. Cotains Domain

A Contains relationship is primarily related to data access.

Conceptually:

Domain A

   |

   | Contains

   ↓

Domain B

This can allow data from one domain to be accessed according to the configured domain relationship without creating the same process inheritance as a parent-child relationship.

1. Visibility Domain

Visibility provides another mechanism for allowing users to access data across domains.

For example:

User

 |

 | Visibility

 ↓

Other Domain's Data

This can provide persistent access to data across domain boundaries.

Because Visibility can broaden data access, it should be configured carefully.

Domain Separation and Data Separation

Data separation is one of the most important aspects of Domain Separation.

A domain-separated table may contain records belonging to different domains:

Record	Domain
INC001	Domain A
INC002	Domain A
INC003	Domain B
INC004	Domain B

Domain Separation and Business Logic

Domain Separation is not limited to data.

Business logic can also be associated with domains.

For example:

                 Parent Domain

                             |

                 Business Rule

                             |

              +--------+--------+

              |                         |

          Child A            Child B

A business rule or other configuration defined at a higher level may apply to child domains depending on the domain configuration and type of application artifact.

This allows organizations to maintain:

• Common functionality
• Domain-specific functionality
• Shared processes
• Domain-specific processes

Domain Separation and the Domain Picker

Users working in a domain-separated environment may have a domain picker that allows them to select their working domain.

Conceptually:

Domain Picker

     ↓

Select Domain

     ↓

User works within that domain context

     ↓

Create / View / Update records

The selected domain can influence the records and configuration available to the user.

However, the domain picker should not be confused with security by itself. Actual access is determined by ServiceNow's domain hierarchy, user permissions, domain relationships, and other security mechanisms.

Domain Separation and Global Records

The global domain is another important concept.

Some records can exist at a global level and may be available across domains depending on the type of record and configuration.

Conceptually:

                 Global

                     |

        +----------+----------+

        |                              |

     Domain A              Domain B

Therefore, when designing a domain-separated implementation, it is important to decide which records should be global and which should belong to a specific domain.

Domain Separation vs ACLs

A common question is:

Is Domain Separation the same as an ACL?

No.

They address different aspects of access control.

ACL

ACLs control whether a user can perform operations such as:

• Read
• Write
• Create
• Delete

based on configured security rules.

Domain Separation

Domain Separation establishes the domain context and boundaries within a shared instance.

A simplified way to remember it:

ACL

 ↓

"Is this user allowed to perform this operation?"

Domain Separation

 ↓

"Which domain's data/process context is this user operating within?"

In a real implementation, these mechanisms can work together.

Domain Separation vs Separate Instances

Another important architectural decision is whether to use Domain Separation or completely separate ServiceNow instances.

Domain Separation

             One Instance

                       |

        +---------+---------+

        |                           |

     Tenant A            Tenant B

Separate Instances

Instance A              Instance B

       |                            |

 Tenant A                Tenant B

Domain Separation allows multiple organizations to share a ServiceNow instance while maintaining logical boundaries.

Separate instances provide stronger physical platform separation but require managing multiple instances.

The appropriate architecture depends on business, security, operational, and technical requirements.

Common Developer Mistakes

1. Treating Domain as Just Another Field

Domain Separation is an architectural capability, not simply a field containing a domain value.

Developers should understand how domain processing works before adding custom domain conditions.

1. Adding Domain Conditions Everywhere

A developer might write:

gr.addQuery('sys_domain', current.sys_domain);

without first understanding how domain access is already being handled.

This can result in unexpected behavior.

Always understand the platform's domain behavior before adding custom filtering.

1. Not Considering Child Records

Suppose we have:

Parent Record

      |

      +---- Child Record

      |

      +---- Child Record

The developer should understand how the domain model applies to both parent and child records.

Incorrect domain handling can lead to unexpected visibility or processing behavior.

1. Misunderstanding Visibility and Contains

Visibility and Contains are not simply different names for the same functionality.

They have different purposes and should be selected based on the required access model.

1. Creating Too Many Domains

A complicated domain hierarchy can become difficult to maintain.

Before creating a new domain, determine whether an existing domain structure can satisfy the requirement.

How to Troubleshoot Domain Issues

When a record is unexpectedly visible or invisible, don't immediately start changing ACLs or scripts.

Follow a structured approach:

Identify the user

        ↓

Check user's domain

        ↓

Check selected domain/context

        ↓

Check record's domain

        ↓

Check domain hierarchy

        ↓

Check Contains / Visibility relationships

        ↓

Check ACLs

        ↓

Check application logic

        ↓

Check custom scripts/queries

This approach helps determine whether the problem is actually related to Domain Separation or to another security mechanism.

Best Practices

Keep the Domain Hierarchy Simple

Create domains only when there is a clear business requirement.

Define Governance Early

Before implementing Domain Separation, establish:

• Domain ownership
• Domain hierarchy
• Data ownership
• Access requirements
• Administrative responsibilities

Test Using Multiple Domain Users

Testing should include users from different domains to verify:

• Record visibility
• Record creation
• Record updates
• References
• Reports
• Notifications
• Flows
• Integrations

Be Careful With Cross-Domain Access

Cross-domain access should be explicitly designed rather than implemented through ad-hoc scripts.

Consider Performance

Domain relationships can affect queries and data access. A well-designed domain hierarchy is important for both maintainability and performance.

A Simple Mental Model

The easiest way to understand Domain Separation is:

                  ServiceNow

                          |

              Domain Hierarchy

                          |

          +----------+----------+

          |                              |

       Domain A              Domain B

          |                              |

        Data                          Data

        Users                        Users

        Processes             Processes

Then remember:

Parent / Child

       ↓

Data + Process relationship

Contains

       ↓

Primarily Data relationship

Visibility

       ↓

Cross-domain Data Access

Conclusion

Domain Separation is a powerful ServiceNow capability for supporting multiple organizations or tenants within a shared instance.

Understanding Domain Separation requires more than knowing the sys_domain field. Developers should understand:

• Domain hierarchy
• Parent and child domains
• Global domain
• Contains domains
• Visibility domains
• Domain context
• Data separation
• Process separation
• ACL interaction
• Cross-domain access
• Performance considerations