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

[Daniel Draes]

That seems not to be true

Infact, I see Sales people sometimes trying to sell it when they think it could be useful. Technical discussion and the real reasoning for it frequently shows it is not necessary. As Aaron points out, the theory is simple, in practice life looks completely different.

Besides being an MSP I have not seen any customer use case that would be much simpler with domain separation compared to without. The drawbacks of using domain separation usually outweigh any benefit quickly - again, with the exception of being a MSP.

First thing to note for me is usually:

Domain Separation is no tool to separate data (yes, it can do it but there are numerous simpler ways than domain separation) !!

I would recommend to get a ServiceNow architect involved before you make the final decision wether to use domain separation or not.

[raprohaska]

Agree and disagree. Data segregation via domain separation is nice. It happens at a SQL level granting performance benefits beyond data segregation benefits, it is highly optimized.

Process separation on the other becomes tricky if users sit at different level and even more tricky if they create data in sub domains. Your options are to use the domain picker and toggle domain scope OR limit the use of things like before insert business rules.

Requests that cross domain boundaries can also be tricky. Of example, if you have a shared CI at a parent level. Users within the sub domains cannot see that data, thus cannot pick that data. A user existing in the parent domain, would need his session domain be that home domain, open the sub domain request, and then toggle domain scope to gain access to the CI.

Here is a thread I created discussing the challenges of domain separated workflows: Domain Strategy with Domain Separated Workflows

Domain Separation brings a lot of functionality including optimized performance and simplification of segregating data. But to fully utilize the power of domain separation increases complexity of usability and forces the user base to understand the domain structure they support.

***Be prepared to use record producers and interceptors to drive the user into the proper domain if use of the domain picker is too complex.

[Daniel Draes]

Why would the data separation be better than the use of a before query business rule? This would also amend the SQL query to the DB, similar then domain sep will do it. Designed properly this is also not a real performance impact. We have used that on multiple occasions already. A prominent example is also the Simple Record Separation module from Ben.

[raprohaska]

Sure you can develop something that performs perfectly well... but Domain Separation does it out of the box without extra coding. You want to segregate data for a new client or division.... add sys_domain to the table and boom, it works.

There are many ways to tackle a problem, it is the art and beauty of software development. Depending on the ability and knowledge of your team, good implementations may or may not be in your bag of tricks. Depending on your timelines, you may or may not have the time to build customization for every table. And covering any/all back doors to data access like injected scripting or even use of OOB web services has to be considered.

If you think about the ServiceNow motto, to be codeless as much as possible, OOB features help that. And, I think utilizing OOB features will almost always be more optimized and easier to extend than what the average admin can develop **NOT ALL admins, average admins.

I guess I'm just saying, Domain Separation does add complexity and introduce challenges and is needs to be evaluated and considered carefully. I just don't think it fair to say that there is always a better way or that it is never relevant. I would tend to agree that it is mainly for MSPs though I can imagine it working well for inner company divisions creating an easy generic way to create top-down reporting structures without a lot of scripting.

Without knowing the exact requirements, deadlines, and the team's level of knowledge/ability, we can only offer suggestions, pros and cons of the feature.

One last note, ServiceNow doesn't offer the greatest SQL tools and the ability to manage indexes is not optimal. I cannot look at a SQL execution plan nor do I get suggested indexes. Once an index is created, it can only be removed by a request to ServiceNow and since it may be difficult to see how multiple indexes affect one another, the management of indexes become pretty key to optimization of queries that segregate data.

There are many tools in the ServiceNow handbag. Its all about using the right tool for the right job. It takes time learning and weighing pros/cons to make a wise decision.

If you choose to use Domain Separation, make sure to take your time and consider your domain structure so that it is flexible and can grow with your business. Changing domain structure after the fact can be tricky.

Good luck to Dominic and thanks to all for the spirited conversation.

[robjohnwilson]

This is so true Chuck, we've seen customers go the route of Domain Sep because it seemed like it was what they needed without considering the overhead in terms of maintenance and introduced complexities. In most cases logical data separation (via the SHARE update set or otherwise) will satisfy use cases outside of the MSP world.