Single Global Instance?

[DmytroD_]

Has anyone reached a point where regional requirements influenced the decision to use a separate ServiceNow instance rather than maintaining a single global one?

I'm curious what typically becomes the tipping point. Is it regulatory requirements, operational constraints, data handling policies, or something else entirely?

Would be interested to hear how others approached that decision.

[Dr Atul G- LNG]

Hi @DmytroD_ 

Yes mate, 100%. I’ve had this experience as well. While working on a migration project involving domain separation, one of my customers refused to use domain separation and did not want to share their data in a single place where multiple tenants are present. Based on this, a single-instance setup is required. It is very common for customers to prefer a standalone instance for regulatory reasons.

[Tanushree Maiti]

Hi @DmytroD_ 

Interestingly, this same topic was discussed in depth during my CTA class for about 30 minutes. As an experienced Domain Separation specialist, my view is that

When to Choose Non-Domain Separated Instances

Use a single, non-domain separated instance (or multiple isolated instances) when you have standardized processes across your organization.

• Your parent company requires standardized global processes, workflows, and centralized reporting.
• You want to avoid the high architectural, development, and licensing costs associated with maintaining a domain-separated environment.
• You want to simplify future upgrades and testing without needing to validate configurations against multiple varying domains.
• Client choice to use  non-domain separated instance

When to Choose Domain Separated Instances

Consider domain separation (partitioning a single instance into multiple logical domains) primarily if you are an MSP or a large enterprise acting like one.

• You need to host multiple distinct clients on a single ServiceNow instance while completely hiding data and specific workflows from one another.
• There are legal, regulatory, or strict corporate compliance requirements that force you to keep data logically isolated.
• Different business units or subsidiaries require entirely different automation, UI policies, and business rules, but upper management still demands centralized, global visibility.
• It significantly reduces total cost of ownership  compared to maintaining multiple separate instances by consolidating infrastructure, administration, and licensing costs

[DmytroD_]

Thank you for the detailed breakdown.

You mentioned legal, regulatory, and compliance requirements that may require data to remain isolated. In your experience, do organizations typically try to address those requirements through Domain Separation first, or are there cases where they eventually move to separate instances instead?

[ben_hollifield]

There are organizations that think they need Domain Separation or a separate instance, but they truly just need data segregation to limit record visibility to the appropriate groups/departments/companies/etc. This can be a great alternative - much less cost & maintenance than DS or separate instances.

There are ways to achieve this natively using ACLs, etc. However, if you're looking for a simple solution that is certified and easy to manage, Yansa Labs maintains the most popular data segregation option in the ServiceNow Store. Worth knowing about - feel free to reach out if you need to know more:

Simple Data Separation

• Product Page
• Docs
• ServiceNow Store

[Paer]

This is indeed a challenging topic that depends on many factors.

We had a similar decision to make 2 years ago, where we had 4 internal organisation that needs to collaborate, all today having their own instances. We had to decide between merging all to one single tenant, merging all to a domain separated environment, or stay with separate instances and integrate them.

For us, we had a few, decisive requirements:

- The separate business units needed to have some autonomy to design their own processes, manage their own data and decide upon their own integrations (if you for example have various versions of SAP or MS to integrate with, it can be tricky on one instance)

- The separate business units needed autonomy to purchase some SN products independently, and some SN license models do not accommodate for that in domain separation of single tenant

This and a few other consideration, led us down the path of separate instances, highly integrated to allow cross unit data analysis and collaboration.