Domain Separation or Data Separation?
While the Plugin “Domain Separation” is a very heavy and powerful horse you could bet on, it might not always be the best solution.
There are cases where Domain Separation is the most fitting solution. Yet these cases are rare. More often, you actually just want to change visibility of data — and therefor parting data into different domains.
I’ve also published a Whitepaper on that, supporting your decision whether to really use Domain Separation as such or another possible solution. You can find it here.
Data Separation Solution
If a pure separation of data into different domains is your actual requirement, you might want to base on this reference implementation.
It uses Query Business Rules to filter out records and Before Business Rules to enforce data security by canceling updates on records a user shouldn’t actually see.
The rest behaves like the ServiceNow® Plugin “Domain Separation”:
- a domain hierarchy is used
- primarily company based (company reference on the user record)
- additional visibility domains can be defined
- domains can cross-contain other domains
It follows the same pattern as the Plugin, which is documented well in the Docs:
https://docs.servicenow.com/csh?topicname=c_DomainSeparation.html#c_DomainSeparation&version=platform
The only exception is that it doesn’t implement a mechanism to allow logic/process deviations. But: is that what you need?
It is what it is: a lightweight, yet powerful tool to separate data in the same processes for different domains.
Download
You can download the Update Set here.
Technical Documentation
The main component installed with Data Separation is the Module “Data Domains” within the Application “System Security” (Table u_data_domain). This resembles ServiceNow’s sys_domain or u_domain (on older Versions) of Domain Separation. The behavior is very similar so that the basic documentation from can be applied analogously to this solution.
Besides that I created an overview of the solution design to understand its operation.
Common concepts to the Domain Separation
-
- A user’s domain is derived from the company it belongs to
- The domain can be overriden per user
- A user can belong to multiple domains
- one directly referenced
- many additional domains per related list
- many additional per group membership as groups can belong to domains as well
- Domains are organized hierarchically
- Additionally, domains can cross-contain other domains
Differences to Domain Separation
-
- Domains don’t apply to admin users / there is no domain switch for an admin
(the normal impersonation feature is sufficient as only data is affected) - you can’t have minor or moderate process differences (see Domain Separation or Data Separation? for a guide)
- it doesn’t use a Domain Path as it isn’t needed here
(a user’s available domains (sys_id’s of them) are determined at login time and cached) - it uses a field “u_data_domain” to determine a company’s, a user’s and a record’s domain
- it uses three business rules per separated table (“out of the box” for task and cmdb_ci):
- a query business rule to constrain the result set accordingly
- a before business rule to prevent updates on records in a domain a user doesn’t have access to (for additional security)
- a before business rule to derive a new record’s domain from the parent record or the user’s primary domain creating the record
- it can be deactived by disabling the above mentioned business rules
- it can be enhanced to further tables by copying the three business rule from task or cmdb_ci to the table, the data separation should be applied on and creating a reference field “u_data_domain” on the table as well (analogue to task or cmdb_ci)
- it can be uninstalled completely by removing the controlling tables and the u_data_domain field(s)
- Domains don’t apply to admin users / there is no domain switch for an admin