Understanding Domain Seperation in ServiceNow with a practical example

[TharaS657398130]

If you find this content helpful, please upvote, thank you.

When I first started learning Domain Separation in ServiceNow, I kept asking myself:

Why isn't Global the parent of all domains?

What is the purpose of TOP?

When is the Default domain actually used?

Why are some records shared while others are isolated?

After experimenting with Domain Separation in my Personal Developer Instance (PDI), I realized the official documentation explains what these domains are, but I needed a simpler way to understand why they exist.
The analogy below is what finally made everything click for me.

Imagine your ServiceNow instance is your house.
The entire building, the architecture, and the foundation of the house is TOP. Think of it as the root or the parent of every domain in the instance.Now, no one actually sleeps on the roof or lives there, right? 

Similarly, TOP isn't a domain where users normally work or where business records are created. It simply exists to hold the entire domain hierarchy together.
Once you step inside the house, the first place you enter is the common hall, which represents the Global domain. Although Global is just another domain in the hierarchy, think of it as the shared space in your house. This is where you'll find the TV, sofa, Wi-Fi router, dining table, and other things that everyone in the house uses. In ServiceNow, this is where you would typically keep shared components such as common Script Includes, shared Business Rules, utilities, or any logic that can be reused across multiple domains.
Now let's walk into the bedrooms.
Bedroom 1 belongs to Netflix. Everything inside this room belongs only to Netflix—its own documents, laptop, clothes, and personal belongings. Likewise, the Netflix domain contains its own users, incidents, branding, customer-specific Business Rules, and other records that should remain isolated from other domains.
Bedroom 2 belongs to Amazon. Just like Netflix, Amazon has its own documents, laptop, clothes, and everything else that belongs only to Amazon. The same idea applies in ServiceNow—Amazon's records stay within the Amazon domain and are not visible to Netflix.
Finally, imagine someone unexpectedly arrives at your house. They aren't from Netflix or Amazon, and you don't know which room they belong to yet. Instead of assigning them to a bedroom immediately, you let them stay in the guest room. That's exactly how I think of the Default domain. It's the fallback place used when ServiceNow cannot determine which domain a record should belong to (depending on your implementation and configuration).

If I'm currently working in the Global domain and I create a user or an incident, the record is created in Global because ServiceNow already knows my current working domain.
Similarly, if I'm working in the Amazon domain and create a record, it belongs to the Amazon domain.
In both these cases, ServiceNow already knows where the record should go, so the Default domain is never involved.
The Default domain comes into the picture only when ServiceNow cannot determine the appropriate domain.
For example, imagine an Import Set creates 500 users, but the import file contains only the user's name and email address. There is no domain information, and there are no rules to determine which domain each user belongs to. In that situation, ServiceNow can use the Default domain as a fallback (depending on your instance configuration).

After understanding the domain hierarchy, the next important thing to know is that Domain Separation does not apply to every table in ServiceNow. Many people think that once Domain Separation is enabled, the entire instance gets divided and every single record becomes separated. But that is not how it works.
Tables such as Users, Incidents, Cases, Problems, and Changes need Domain Separation because the data belongs to a specific company. For example, an incident created by a Netflix employee should only be visible to Netflix users, and an incident created by an Amazon employee should only be accessible by Amazon users. Each record is associated with its respective domain using the sys_domain field, ensuring that each company’s business data remains isolated even though they are using the same ServiceNow instance.
However, some tables like Country, Language, and Currency do not require Domain Separation. These are common reference data shared across the entire ServiceNow instance. For example, both Netflix and Amazon may have users from countries like India or the USA, use languages like English, or work with currencies like USD and INR. There is no need to create separate Country, Language, or Currency records for each company because this information is standard and applies to everyone. These tables remain shared across domains, while only business-specific data is separated.

The key takeaway is that Domain Separation is not about creating multiple ServiceNow instances inside one instance. It is about creating a logical boundary where different organizations can securely manage their own data while still sharing the same platform.
Think of it like the same house with different rooms. Each room has its own private space, but the foundation, structure, and common areas are still shared. Similarly, ServiceNow uses domains to separate business data where isolation is needed while keeping common platform resources available across the instance.

If there's any ServiceNow topic you'd like me to explore next, feel free to mention it in the comments. I'll be happy to cover it in a future post.