CAD Guide

Domain Separation in ServiceNow

Introduction

Domain Separation allows a single ServiceNow instance to serve multiple tenants — each with isolated data, configurations, and users — while sharing infrastructure and some global configurations. It's primarily used by Managed Service Providers (MSPs) who support multiple customer organizations on one platform, but also by large enterprises that want strict data isolation between business units.

What Domain Separation Solves

Without Domain Separation, all data in a ServiceNow instance is visible to all users (subject to ACLs). For a scenario where Acme Corp and Beta Ltd both use your MSP's ServiceNow instance, a user from Acme should never see Beta's incidents — and vice versa. Domain Separation enforces this at the data model level.

Domain Hierarchy

Domains are organized in a tree:

Global (top domain — shared configurations)
    └─ Acme Corp
          └─ Acme IT
          └─ Acme HR
    └─ Beta Ltd
          └─ Beta Operations

Records in Acme Corp are not visible to Beta Ltd users
Records in Global are visible to all domains (unless overridden)
A user in Acme IT can see Acme IT records + Acme Corp records + Global records
A user in Beta Ltd sees only Beta Ltd + Global

How Domain Separation Works

Every record has a Domain field (sys_domain) that identifies which domain owns it. Queries automatically filter to return only records in the user's accessible domains.

// This query automatically restricts to the user's domain
var gr = new GlideRecord('incident');
gr.addQuery('state', '1');
gr.query();
// User in Acme Corp only sees Acme Corp incidents
// User in Global sees all incidents

Domain-Separated Configurations

Not just data — configurations can also be domain-specific:

Configuration	Can be domain-separated
Business Rules	✅ (fire only for specific domain)
Client Scripts	✅
Notifications	✅
SLA Definitions	✅
Service Catalog items	✅
Roles	✅
System Properties	✅

This allows each customer/domain to have their own customized SLAs, notifications, and catalog items while sharing the global platform infrastructure.

Domain Path

The Domain Path is a string that encodes the domain hierarchy:

Global: /
Acme Corp: /global/acme_corp
Acme IT: /global/acme_corp/acme_it
Beta Ltd: /global/beta_ltd

Record visibility uses path prefix matching — a user in /global/acme_corp can see all records with paths that start with /global/acme_corp or are in / (Global).

User Domain Assignment

Each user record has a Domain field. Users only see records in their own domain and ancestor domains:

User: jane.smith@acme.com
Domain: Acme Corp (/global/acme_corp)

Visible: Acme Corp records + Global records
Not visible: Beta Ltd records, Acme IT sub-domain records (unless she's explicitly a member)

Cross-Domain Access

Sometimes a user needs cross-domain visibility — an MSP admin supporting all customers:

User: msp_admin@provider.com  
Domain: Global (/)

Global users can see all domains. This should be reserved for platform administrators, not regular users.

When NOT to Use Domain Separation

Domain Separation adds significant complexity:

Every Business Rule and script must consider domain context
Reporting across domains requires elevated access
Upgrades and testing are more complex
Configuration changes must be carefully scoped

Do NOT use Domain Separation if:

You're a single organization wanting data segregation by department → use Groups and ACLs instead
You want separate Service Catalogs per team → use User Criteria instead
The business unit isolation is about access control only → ACLs handle this

Domain Separation is appropriate only when you need true multi-tenancy — different organizations with completely isolated data on a shared platform.

Implementation Checklist

Activate the Domain Separation plugin before any data is loaded
Plan the domain hierarchy before creating domains
Assign all users to appropriate domains before activating separation
Test visibility as a domain-specific user before go-live
Configure domain-specific SLAs and catalog items for each tenant
Create domain-separated admin accounts for each tenant's administrators
Document which configurations are Global vs. domain-specific

Conclusion

Domain Separation is powerful but complex — it's designed for a specific use case (multi-tenancy on a shared instance) and should not be used as a substitute for simpler access control mechanisms. For MSPs or enterprises with genuine multi-tenancy requirements, it delivers complete data isolation without the cost of separate instances. Plan the hierarchy carefully before implementation, as restructuring domains after go-live is operationally difficult.