Domain Separation and its impacts on other plugins

[Dom Davidson]

Hello Community,

I am presently working with a client who is thinking about implementing ServiceNow, using Domain Separation.   Having the corporate entity of the company reside on global domain level and the other sub-branches of the company in child domains.

One of the questions that came up, where

- What are the impacts of Domain Separation while turning on plugins in the child instances?   Would the parent domain also have the plugin automatically turned on?   Also, would other child instances have this plugin automatically turned too? Are downloads of plugins domain separable?

- Also, if a plugin was turned on and enabled in one of the child instances(say ex.JIRA POC plugin) with all customization captured on the child instance.   Will the parent domain have access to these customization? I am aware Script Include is not domain separable, but what about Business Rules and Client scripts?

- Also, say if the above has been implemented(On child domain, a particular plugin was downloaded and enabled, along with added customizations-UI policies, Business Rules and Client Scripts) and later downstream the parent domain decides to download and implement the same plugin with added customizations(customizations different from child domain) how would this impact the big picture?

I couldn't find any materials regarding the above criteria, hence your expert response is most appreciated.

Much thanks!

-Dominic Davidson

[Michael Fry1]

"Having the corporate entity of the company reside on global domain level and the other sub-branches of the company in child domains." - makes me ask why your going with Domain sep?

I also question why anything is in the Global domain? If in global, it's visible to all domains.

Plugins are global. Obviously you can use a role to limit UI actions, BR's, etc to run in one specific domain.

[raprohaska]

Domain separation applies to any table with a sys_domain field on it. So you can even domain separate custom tables. You can tell if a plugin is domain separated if its tables have that sys_domain field.

First key to understanding and preparing for domain separation is

1. Data flows from Child to Parent

2. Process flows from Parent to Child

Nearly everything in ServiceNow is stored in a table, from BRs to Incidents... in this case BR is process data and Incidents are 'data' data.

The next key thing to understand is that it is important to understand your domain separation properties. Those will dictate how domain separation is applied to new and existing records.
New Records

1.   Will apply process data per the current session domain of the user.

Existing Records
1. If the "Use the domain for the record being viewed as the current domain" is true, then business processes will be applied per the domain of the record.

2.If the "Use the domain for the record being viewed as the current domain" is false, then business processes will be applied per the users current session domain.

Understanding this is really important if you are building out domain separated processes as how it will affect the user experience.

I would highly suggest getting a developer instance (https://developer.servicenow.com/app.do#!/home) and turn on domain separation to get some practice. To really understand, create before and after insert business rules in each domain for incident table. Just have them write a info message to the screen. Create users within each domain. Then start creating incidents from each of the users. You'll see when and how each BR fires. Assignment rules, UI Scripts, UI Policies will follow similar flow as after BRs.

Michael's point to having global data is also a good point too. The only time I would think that anything would get created in the global domain is if you are building a custom application, for which global would represent the OOB configurations of that application.

Domain Separation is simple in theory but adds numerous complexities. It is important to plan the domain structure so that everyone can access the proper data. You need to understand the power and limitations of Contains Domain and Domain Visibility, especially if the client is a true MSP.

Feel to send me a message if you have any questions.

Hope this helps some,

[Chuck Tomasi]

The primary usage of Domain Separation is with Managed Service Providers (MSP). It offers their clients access to their services along with ServiceNow.

Typical commercial organizations do not need (nor want) the overhead of domain separation. Your initial lines concern me that this may not be a good fit for domain separation. Once it's turned on, there's no going back.

I am presently working with a client who is thinking about implementing ServiceNow, using Domain Separation.   Having the corporate entity of the company reside on global domain level and the other sub-branches of the company in child domains.

As Aaron mentioned, understand what it is, how to manage it and if it is the right decision. Unless you are a MSP, I would think twice, or even three times, VERY carefully before going forward with it.

[raprohaska]

According to a conversation I had at my last SNUG, ServiceNow will not grant Domain Separation unless the company is a true MSP? Though I'm sure enough money can always sway that rule.