ServiceNow Domain Separation is designed for situations where one platform instance must serve logically distinct organizations or business entities while controlling which data, processes, and configuration each population can see. It is often described as multitenancy inside an instance, but that shorthand can hide the design work involved. A domain hierarchy affects data visibility, administration, application behavior, reporting, and support, so it should be treated as an architectural decision rather than a filtering feature.<\/p>\n
In the wider practice of ServiceNow platform engineering<\/a>, domain separation sits at the intersection of security and operating model. The platform team has to decide what is genuinely shared, what is tenant-specific, which administrators can cross boundaries, how parent and child domains relate, and how integrations choose the correct domain context. Those choices need to be coherent before large volumes of data and automation depend on them.<\/p>\n ServiceNow\u2019s current guidance positions Domain Separation as a way to isolate data and process behavior within a hierarchy. It also carries meaningful operational overhead and is not a casual feature to turn on experimentally. Organizations should involve ServiceNow expertise before activation and validate that the business requirement cannot be met more simply with ordinary access controls, application scope, or separate instances.<\/p>\n The first design question is why populations need separation. A managed service provider may need customer isolation. A large enterprise may need independent regional or subsidiary processes while retaining a shared platform. A regulatory requirement may demand stricter administrative boundaries. These are different problems even if each can be drawn as a parent with several child domains.<\/p>\n Write the required isolation in terms of users, data, configuration, and administration before choosing hierarchy. Which records must never be visible across tenants? Which services or reference data should be shared? Can a central team support every tenant? Are local administrators allowed to customize behavior? The answers define the domain model more reliably than starting with the organization chart.<\/p>\n This is the same kind of boundary-setting encouraged by clear governance standards<\/a>. A domain should represent an enduring separation principle. If domains are created for every temporary project or reporting preference, the hierarchy will encode short-lived organizational noise into platform security.<\/p>\n Domains are hierarchical. That makes it possible for parent domains to represent shared or overseeing populations while child domains represent more specific tenants. The hierarchy is useful, but inheritance means placement has consequences. A record assigned to the wrong domain can become visible to the wrong population or invisible to operators who need it.<\/p>\n Designers should therefore define where shared records live and how global or parent data is consumed. Reference information, assignment structures, service models, and integration metadata may need a different strategy from transactional records. The goal is to avoid duplicating shared data solely to satisfy a poorly chosen domain tree.<\/p>\n Model review should include examples of records moving through common processes. A request created in one domain might reference a shared configuration item, be fulfilled by a central group, and trigger an integration used by several tenants. Walking through those cases exposes hierarchy problems earlier than reviewing a diagram in isolation.<\/p>\n Domain visibility and ACL authorization solve related but different problems. Domain Separation limits records and configuration according to domain context; ACLs still govern which operations a user can perform on the resources they can reach. A user in the correct domain should not automatically have write access to every record, and a role should not be used to bypass tenant isolation casually.<\/p>\n The principles in ServiceNow ACL design<\/a> remain necessary. Define permissions by responsibility and data relationship, then verify how those permissions behave inside each domain. Security testing should include cross-domain negative cases so the team proves that a user cannot access another tenant merely by changing a URL, query, or API request.<\/p>\n Avoid scripts that manually emulate domain filtering when the platform\u2019s domain mechanisms should own the boundary. Custom filtering logic can diverge across interfaces and is difficult to prove complete. If an exception is required, document why it exists and which users or processes are allowed to cross the boundary.<\/p>\n One benefit of Domain Separation is the ability to vary certain process behavior between domains while retaining a shared platform. That capability is valuable for tenants with legitimately different workflows, but uncontrolled variation can turn one instance into many partially incompatible systems. The platform team needs criteria for which differences justify domain-specific configuration and which should remain standardized.<\/p>\n Shared process designs reduce maintenance cost and make upgrades easier. Tenant-specific behavior should be introduced where the requirement is durable and materially different, not because a local team prefers a different label or sequence. The application architecture described in ServiceNow application design<\/a> still applies: data, logic, security, and automation need coherent ownership even when domain context changes which configuration is active.<\/p>\n Maintain a catalog of intentional domain-specific variations. Without that record, support teams cannot easily tell whether a difference between tenants is expected or drift. The catalog also gives upgrade and regression-test teams a list of behaviors that must be validated separately.<\/p>\n An inbound integration can create serious isolation problems if it inserts records without the intended domain. An outbound integration can expose another tenant\u2019s data if queries run under an account with broad visibility and fail to constrain the business context. Integration design must therefore state how domain is selected, validated, and audited.<\/p>\n Connection accounts should have the minimum cross-domain authority needed for their purpose. If a central integration legitimately serves many tenants, use reliable tenant identifiers and reject ambiguous requests rather than defaulting silently to a shared domain. Correlation values should make it possible to trace which external tenant caused a ServiceNow transaction.<\/p>\n The same principle applies to discovery and CMDB ingestion. CMDB governance<\/a> becomes more complex when configuration data is domain-separated because ownership and source authority must be clear within the tenant model. A connector that ignores domain semantics can undermine otherwise correct identification and reconciliation rules.<\/p>\n Central platform administrators often need broader visibility than tenant users, but broad access should be a deliberate operational role rather than an informal convenience. Separate platform administration, tenant administration, and business fulfillment responsibilities where practical. A local administrator should not automatically receive the same cross-domain powers required by the central platform team.<\/p>\n Support procedures should specify how cross-domain troubleshooting is performed and logged. When an engineer switches context or uses a privileged account to investigate another tenant, there should be enough audit evidence to reconstruct what was viewed or changed. This is particularly important in service-provider and regulated environments where the platform operator has responsibilities to several independent customers.<\/p>\n Test delegated administration after upgrades and configuration changes. A domain model that appears secure for normal users can still have gaps in administration modules, reports, imports, APIs, or background tools used by elevated roles.<\/p>\n A Domain Separation test plan needs more than one tenant. For a given transaction, prove that the owner domain can see and process the record, a peer domain cannot see it, an authorized parent or central role behaves as intended, and shared reference data remains usable. Repeat these patterns for key APIs and automated processes, not only forms.<\/p>\nStart with the tenancy requirement, not the domain tree<\/h3>\n
A domain hierarchy creates inheritance, so parent placement matters<\/h3>\n
Domain separation complements ACLs but does not replace authorization design<\/h3>\n
Process separation should be intentional instead of automatic customization<\/h3>\n
Integrations need an explicit domain context<\/h3>\n
Administration and support need carefully scoped cross-domain privileges<\/h3>\n
Testing has to cover both isolation and shared behavior<\/h3>\n