Two requirements share one name
Domain separation is the right answer for a small number of ServiceNow customers and an expensive mistake for everyone else. It partitions data and configuration so that separate populations genuinely cannot reach each other, and the cost of that partition lands on reporting, integration, upgrade testing and every configuration decision your platform team makes for the next several years. Most of the organisations that ask me for it do not need it.
What the feature does is attach a domain to records and configuration, then filter what every user sees by the domain they sit in. A person in one domain does not see another domain's incidents, and does not see its business rules, notifications or assignment groups either. Visibility stops being a matter of roles alone and becomes a property of the record itself.
Two situations warrant that. The first is a managed service provider running one instance for clients who compete with each other, where a support engineer opening the wrong client's ticket creates a contract problem rather than an embarrassment. The second is a group whose legal structure requires that one entity's data never be reachable from another, usually because a regulator, a works council or the terms of an acquisition say so. Both are real. Neither describes a company that wants HR and IT to stop tripping over each other.
The honest test is must not versus should not
Before anyone draws a domain map, force one question to a written answer. Ask whether the requirement is that these people must not see that data, or whether the requirement is that they should not routinely encounter it. Those are two different requirements with very different answers, and the gap between them is where the wasted money goes.
Almost every request I have been handed turns out to be the second one. HR does not want its cases sitting in the same list the service desk works from. Facilities is tired of being asked about tickets that belong to another team. A business unit wants its own forms, its own queue and reporting it controls. Every one of those describes separation of concerns, and none of them requires that the data be unreachable.
The way to tell them apart is to ask what happens on the day someone does see the record. If the honest answer names a contract clause, a regulator or a lawyer, you are in must-not territory and domain separation deserves a serious look. If the honest answer is that a colleague would be confused and would send an annoyed message, you have a design problem that roles and a proper access request process already solve.
Scoped applications carry most of what people want
A scoped application gives you a namespace of its own, its own tables, its own administration boundary and explicit control over what other scopes may read or write. That covers the separation of concerns case properly, without changing how the rest of the platform behaves. If the boundary a scope draws is not clear to your team, start with what App Engine actually gives you.
Access control does the rest. Roles and groups decide who can open which table, field level rules hide the columns that matter, and query rules filter rows so a user only sees records their group owns. Lists, filters and dedicated workspaces keep each team inside its own work without pretending the rest does not exist. Reporting still runs across everything, and shared data such as one CMDB serving two applications stays shared.
The strongest argument for this route is that you can change your mind. An access control rule that turns out too tight gets loosened in an afternoon, and one that turns out too loose gets tightened the same week. A scope that grew in the wrong direction can be refactored by the team that owns it. None of those decisions constrain the next five years of platform work.
Reporting across domains is the first complaint
Reporting is where domain separation gets discovered by the people who approved it. A report runs in the context of the person running it, so a manager inside a domain sees their own domain's numbers and nothing else. That is the behaviour you asked for, and it is the behaviour that makes a group-level number difficult to produce.
Someone senior will want one figure across the whole organisation within about a month of go-live. Producing it means either a small set of accounts that sit above the domains and see everything, which raises the question of who may hold one, or a warehouse outside the platform that receives every domain's data and joins it there. Both answers work. Neither is free, and neither was in the original estimate.
Decide the reporting model at the same time you decide the domain model, not six months afterwards. Name the people who will hold above-domain visibility, write down what they may see, and agree who approves additions to that list. Teams that skip this grant above-domain access quietly to whoever complains loudest, which undoes the partition they paid for.
Global configuration and inbound records need an owner
Domain separation splits configuration into what is global and what belongs to a single domain, and somebody has to own that line. A domain asks for a new field on the incident form. Either it goes global and every other domain carries it, or it stays domain specific and that form starts drifting from the rest. Handle that ten times without a written rule and you get either a platform nobody recognises or domains that cannot get anything changed.
Integration gets harder in a way that is easy to underestimate. Every inbound record needs a domain, and something has to decide which one. The integration user's own domain, a value in the payload, a lookup on the customer reference, a fallback to global when nothing matches. That decision logic is code with real failure modes, and when it picks the wrong domain the record lands somewhere nobody is watching. A narrow contract per interface helps, because it makes the domain decision explicit rather than implied.
Upgrade and test effort scales with the number of meaningfully different domains, not the number of domains. Five domains running identical configuration cost you almost nothing extra. Three domains with genuinely different forms, approval rules and notification logic mean three regression passes every release, and the release cadence will not slow down to accommodate you. Count the distinct configurations, then decide whether you have the people to test them.
Getting in is hard and getting out is worse
Adding domain separation to a live instance later is difficult and doable. Every existing record needs a domain value, including the closed ones nobody wants to touch, and every piece of configuration has to be classified global or assigned somewhere specific. The work is tedious rather than impossible, and teams do finish it, usually across two or three releases with a data migration nobody planned.
Unwinding it runs much harder, and that asymmetry is the reason this decision deserves real scrutiny up front. By the time anyone wants out, integrations resolve domains, reports assume them, and duplicate configuration has grown across domains that solved the same problem three different ways. Merging that back together means reconciling processes that have genuinely diverged, and it means a named person signing off that these two populations may now see each other's data. That signature is the part that stalls for months.
So before you choose, make one accountable person answer this in writing. Which specific records must be unreachable, by whom, and what happens on the day one of them is seen by the wrong person. If the answer cites a contract, a regulator or a licence condition, build the domain model and budget openly for the reporting and testing that come with it. If the answer is that a list would get cluttered and the wrong team would get asked about tickets, you want a scope, some access control rules and an honest look at whether to build the application at all.
