When to use Domain Separation?

[persahlstrom]

Hello,

I understand that Domain Separation is a way do divide one instance to "multiple instances", is that correct? I'm also wondering in what kind of situation you might have to do it? In my company we are currently having a IT-support group which are the only business entity that use Servicenow as a way of handling incomming cases. Now, we want another business enity within our company to be able to use Servicenow, but not in the same way as our IT-support group. Might this be a typical situation to use domain separation or could there be another solution? I'm pretty new to Servicenow and it's amazing features so please be gentle and bare with me

Best regards,

Per

[syedfarhan]

Hi Par,

Few more

Domain separation does two things:

1)Separates data

2)Separates administration (workflow, policy, and UI definition)

Domain separation is best for those organizations that want to:

Enforce data separation between business entities.

Customize business process definitions and user interfaces for each domain.

Use a single instance of ServiceNow to maintain global processes and global reporting.

Domain separation is extremely well suited for managed service providers (MSPs) and global enterprises with unique business requirements in various areas of the world. Domain separation is incredibly powerful and flexible but requires ongoing discipline to ensure that new domains do not conflict with existing domains.

Thanks

[Uncle Rob · Accepted solution]

Per,

Here's the straight answer.   The use case you describe is probably the worst justification for domain separation possible.   Further, it undermines one of the most important advantages of ServiceNow (acting as a single source of engagement for service consumption).   Not meaning this as a slight against inexperience, just wanting to give you a super clear answer.

Consider the following:

- How does separating the domain help you customers engage the services within the company?   (hint: it doesn't)

- Why 2x the labor required to manage what could be a single deployment?

- Domain separation is irreversible.   If you find out a year from now it was the wrong solution to the problem, then it sucks to be you.

- Most existing and emerging services are not naturally silo'd.   Take onboarding for example.   List out all the players involved in employee acquisition and you have recruiting, benefits processing, legal, training, facilities, security, and IT too if you're into that kind of thing.   The service owners who call for their own privately managed instance of SN (usually via domain sep) seldom have to tell the stakeholders "Hey, if you want to hire someone, please enter a request into these 8 different systems".

The whole point of ServiceNow is to put as many business services as possible into one instance, to reap the benefits of multi-participant workflow, task relationships, unified consumption platform, and collapsed development/support resources.

[persahlstrom]

Wow.. alright, fair enough

Thanks for a great response!

[patrickd2]

Nice Robert!

This clearly articulates what I was trying to get at with make that decision only if you have to.   The power of the platform comes from a single source of truth where you can leverage the data from multiple organizations as a single company.   Domain Separation removes this benefit and does increase the work to manage the instance and apps proportionally to the number of domains.

Irreversible is also a great point.   Once you start down the path of Domain Separation, forever will it dominate your destiny.

[Uncle Rob]

Now... stakeholders may also be asking for their own separately managed space for a more insidious reason.   It is likely the current "owner" / primary user of ServiceNow could have grown into the platform as if they'd be its only user-base.   The platform may be so overgrown and customized for a single use case that it *appears* a separately managed space is the only option.

As bad as this position is, re-architecture is still the cheapest and least risky long term option by a mile.