ServiceNow Domain Separation, is it right for your business?

Multiple licenses or Domain Separation? You may be asking yourself this question now or may sometime in the future. One reason you may ask yourself this question is you’re a MSP.  Another reason is your organization has a strong need for separation between business units or entities within your organization.  Whichever situation you are in, this blog is here to help.  Let’s go in depth with Domain Separation, the caveats, and when it should be used.

Firstly, what exactly is Domain Separation? ServiceNow officially defines it as: Separate data, processes, and administrative tasks into logically defined domains. The best use case for Domain Separation is if you are an MSP – Managed Service Provider. Domain separation is the way to provide Multi-tenancy support while only officially having one ServiceNow instance. There are pros and cons to going this route. The biggest advantage is you save on licensing costs while only having one instance. However, if your instance is far from baseline with global customizations, you may want to reconsider. If you need complete and total separation of all system properties and do not require global reporting or global processes, then separate instances are the best option.

Domain separation is best for those customers who:

• Need to enforce absolute data segregation between business entities (data separation).
• Customize business process definitions and user interfaces for each domain (delegated administration).
• Maintain some global processes and global reporting in a single instance.
• Separate data between customers or sub-organizations.
• Have minor or moderate process differences only among customers or sub-organizations.

How does domain separation work?

As seen above, each domain has data separation that is specific to its respective domain. Members of a domain see only the data contained within their domain or child domains. If it is a parent child relationship, the parent will be able to see data in its own domain as well as it’s child domain. By default, all users and all records are members of the global domain unless an administrator assigns them to a particular domain. For our instance, I used our Azure AD tenant. In Azure you can find the ServiceNow Enterprise App. During user provisioning I set the Mapping as companyName from AD to the sys_user.company field which is a reference to core_company. With domain separation you can organize it so specific companies get added to specific domains.  Once you assign a user or a record to a domain, the instance compares the user’s domain to the record’s domain to determine whether the user can view the record. Users in the global domain can see all records, regardless of the record’s domain settings. If a user is a member of another domain, then there is no single visibility setting that allows users to see across domains or allows users to see records at a higher level in the hierarchy.

Note: Guest users must be part of the global domain.

In general, data defined at a higher level in the domain hierarchy is not visible at lower levels in the hierarchy. However, the following records behave like policies:

• Form sections
• Options in a choice list

When defined at a higher level in the hierarchy, these records are visible in child domains.

For your Service Portal, you can go a few different ways with it. Elements of the Service Portal platform such as settings, portals, pages and widgets cannot be domain-separated. However, the data within widgets does display, based on domain. Separate portals with different URLs can be created to provide different experiences for different domains. In our instance, we opted for different Service Portals with different URLS. This way users can have a more customized experience.

Inbound Email actions are probably the trickiest part of domain separation, we needed a good way for the instance to be able to tell whether to create an Incident or a CSM Case. Thankfully you can just separate these by user roles. When a user emails into the instance, it looks up the user, finds out what roles it has, and the inbound action is triggered if all the role criteria is met. This is the simplest solution to inbound actions.

Overall, ServiceNow did a great job with domain separation. The caution I would provide is – challenge yourself on why you can’t live on a single instance without domain separation prior to making the decision to move forward.  If you are close to baseline and do not have complex needs for your company, domain separation may be the answer for you. I am excited to move forward with domain separation as it fits our business needs.