At Knowledge19 I was a member of the Genius Lounge staff for the Domain Separation topic. Many customers were coming and asking about Domain Separation, how to apply it in their companies. From the discussions I have often seen that they actually do not need Domain Separation. They saw it as a solution for their internal issues in the cooperation among different business units. This experience has insipired me to write series of Community artiles around the domain separation. Content of this article expects some level of Domain Separation understanding, at least basic principles and usage.

Domain Separation is a very powerful feature. But it also brings with a lot of complications, such as:

• extended testing requirements (especially when process separation is used)
• cross-domain visibility and functionality issues (people not seeing needed information, some cross-domain functionality restrictions)
• domain-separated CMDB complications with shared infrastructure Configuration Items (one Configuration Item used by many customers in many domains)
• shared monitoring tools and data providers that are not domain-aware (tools contain data from many domains without any information that could be used to identify the domain)
• and many more, not talking about development complications with unwanted process overrides, updates done in wrong domain etc.

Rule #1, 2 and 3: Do whatever you can to avoid domain separation. Use it only when it is really needed and there is no other option.

Question regarding applying a Domain Separation should be answered BEFORE you will begin with any development. It is not recommended to apply domain separation to already live (in production) instances. Technically it is possible but extremely complicated with a lot of data post-processing (moving data to correct domains etc.), significant risk of issues and significant service break time (depending on the amount of data).

When to consider Domain Separation?

I will put aside clear situations when some Managed Service Provider (MSP) needs a domain separation, those are usually very clear cases. And I will focus on enterprise segment based on the common situations presented by customers asking about Domain Separation. If I should simplify all the situations, it is possible to express them as "We have 2..N internal departments that do not want other others to see their data and/or want to use different processes."

This is the situation where you MOSTLY do NOT need to apply Domain Separation. Decision whether Domain Separation should be used or not depends on one key question: "Is it based on a legal / regulatory requirement?".

If the reason is NOT legal / regulatory-based, it is often nice-to-have feature that may - and should - be overriden by a C-level management decision. Having extra cost because of Domain Separation, with all the complications, is not a solution for departments being unable to agree on the common process and/or data visibility.

What are the alternative solutions?

There are alternative solutions that are able to provide functional similar (but limited) to a Domain Separation. In most of the cases those solutions may be enough for internal departments.

Alternative for Data separation

There are 2 main situations when Data separation is usually applied:

User should be able to see Data that belongs to his/her area - department, unit etc.

The most common Data where the visibility is usually restricted are Configuration Items (CMDB) and tickets (Incident, Problem, Changes etc.). As a solution it is possible to use combination of ACLs and before-query Business Rules. From the performance perspective I would recommend to use before-query Business Rules.

Usage of before-query business rules only is not sufficient, they can by bypassed several ways. Before-query business rules are in place to improve performance only!

• create custom role e.g. "full_visibility" and grant it to all users that should see all data (admins, integrations, MID server accounts etc.)
• create custom ACLs for the target class(es)
• create custom before-query Business Rule for required tables (usually "task" and "cmdb_ci") and for all users WITHOUT the custom "full_visibility" role add extra condition(s) to the EncodedQuery so they can see required data only (department, unit etc.)

(function executeRule(current, previous /*null when async*/) {

	// role validation (!gs.hasRole("full_visibility")) is part of the Business Rule Conditions
	// task.company = user.company
	var extraQuery = "company=" + gs.getUser().getCompanyID();
	
	if(current.getEncodedQuery() == ""){
		current.addEncodedQuery(extraQuery);
	}
	else{
		current.addEncodedQuery("^EQ^" + extraQuery);
		// ^EQ^ is needed to handle ^NQ (big OR) conditions
	}						
	
})(current, previous);

This solution is sufficient in the situation where each department, unit etc. is fully isolated from others. If there are users that require access to more than 1 department / unit, you may need to create custom role for each department / unit and before-query Business Rule to add multiple "OR" conditions to the Encoded Query. However, in this situation you already start to build custom Domain Separation. This custom solution may be sufficient for 3 - 5 departments / units but as their number - together with cross-unit visibilities (roles granted) - grow, it may be better to consider Domain Separation.

Described approach with ACLs and before-query Business Rules is applicable to a few classes only. Trying to apply this to all tables would mean extreme effort not only to implement it but to validate after each upgrade. Again, if you need to protect majority of the data inside the ServiceNow, use Domain Separation instead.

User should be able to see Data that are directly assigned to him/her

This solution is often applied to external users (e.g. vendors) working in the backend and implementation is very similar to the previous one. Create custom role e.g. "external_vendor", ACLs and custom before-query Business Rule should restrict access to tickets assigned only to groups where user is member of.

(function executeRule(current, previous /*null when async*/) {

	// role validation (gs.hasRole("external_vendor")) is part of the Business Rule Conditions
	
	var extraQuery = "assignment_groupDYNAMICjavascript:getMyGroups()";
	
	if(current.getEncodedQuery() == ""){
		current.addEncodedQuery(extraQuery);
	}
	else{
		current.addEncodedQuery("^EQ^" + extraQuery);
		// ^EQ^ is needed to handle ^NQ (big OR) conditions
	}

}

Alternative for Process separation

The main official recommendation is to stay baseline (out-of-the-box) as much as possible. Any customization means cost to implement and maintain, with a risk of domino effect. One customization may lead to others. Yes, process separation allows to configure different processes ... but they are high limitations:

• 80% of the implementation should be baseline (the same for all domains)
• 15% should be configurable via lookup tables etc.
• 5% are actuall process overrides in lower domains

Looking at those figures, process separation is actually highly limited if you want to keep your instance healthy and upgradable without major effort. You can use process separation for many objects - forms, fields, UI Actions, UI Policies, Business Rules - but there are objects where it cannot be applied - e.g. Script Includes. And many functionalities are actually depending on Script Includes. Once your customization reach the level where you need to customize Script Includes, adding "If Domain = ABC" conditions, you are in troubles. It means that objects that are "safe" to customize are limited - forms with fields, Business Rules - but it is better to do NOT touch state model and Script Includes.

Most of the custom requirements regarding processes are not so much around states - it is easy to train people using new states - they are around the data. What fields are displayed and mandatory. This is usually much more complicated discussion than accepting baseline state model.

To have custom fiews it is not necessary to have process separation, you can use e.g.:

• UI Policies per unit / department
• View rules that contains specific view for the department / user (https://docs.servicenow.com/bundle/orlando-platform-user-interface/page/administer/navigation-and-ui/task/t_CreateAViewRule.html)
• Custom data driven solution (custom table to store field configurations with conditions, fetched by before-display Business Rule, stored into the scratchpad and processed by an on-load Client Script)

Also, Business Rules may contain conditions tight to Department / Unit, there is no need for a process separation.

Conclusion

Domain Separation is not the only solution how to achive flexibility in terms of data visibility or different processes. It is necessary to consider the real situation, whether Domain Separation is the best fit or not. But the decision should be done based on the business needs, not wishes of people.

The next chapter (coming early 04/2020) will be about the domain structure best practices and multi-instance architecture to support MSP use cases.

Update:

• Domain Separation, part 2: Instance(s) Architecture
• Domain Separation, part 3: How to structure domains