Domain Separation part 1 article was about the decision if the Domain Separation is actually needed or not, Domain Separation part 2 focused on the Instance(s) Architecture. This article, part 3, describes structure of domains, where to locate process overrides, common mistakes in the design.
In the beginning let's look at the domain structure. Rule #1: Domain hierarchy IS NOT THE SAME AS company structure(s). Domain hierarchy consists of several layers, their exact setup (and if they even exists) depends on the Domain Separation usage (process separation, data separation or both, security requirements etc.).
The following picture shows key layers of the Domain Separation hierarchy.
Process Layer
If you consider using the Domain Separation to separate processes, process domains are usually located right under the TOP domain. If you plan to use data separation only with the same processes for everybody, this layer should be skippped. In this situation it is also the best to disable process separation and keep data separation only. You can disable it via Domain Admin => Configuration and switching off the "Enable Delegated Administration" or by a direct modification of the "glide.sys.domain.delegated_administration" property.
When the process separation is disabled, process overrides in lower domains are not created. However, you can always enable it again later on.
Process Overrides
Official documentation (Orlando release) states that "Overrides from global processes" are done in the TOP domain. From the practical experience, I do not recommend to do any process overrides in the TOP domain. Why? Let's take a look what happens when you modify some e.g. Business Rule in the TOP domain: it creates a COPY of the baseline Business Rule (using sys_override field) in the TOP domain.
This is equivalent to the old best practice to disable baseline script, make a copy and place your customizations there. If you do so, there is no conflict triggered during the upgrade process and you cannot compare your custom version with the baseline script. In practice, you do not know if something has been changed in the baseline script and you must include it in your custom version. Until somebody realize this during the testing (the best case) or raise an Incident already in production (the worst case).
For that reason, if you need to customize something for all sub-domains, do it directly in the baseline script, in the global domain. Do not create an override in the TOP domain.
Security Layer
The Security Layer should provide groupping of underlying customer domains per security (visibility / access) restrictions. This groupping is essencial from the manageability and performance perspective, as you should always grant domain visibility as high in the hierarchy as possible. Do not add direct domain visibility to each customer domain separately.
Reason for this groupping is how the domain visibility (or contains domain) is evaluated on the database level. Every "contains" or "visibility" generates "OR sys_domain LIKE '<domain path>%'" in the database query. If some user has 50 domain visibilities, there is 50 times "OR" condition in the query - and performance is highly impacted.
Let's look at the following picture with an example of the domain hierarchy. Picture does not show process layer, only layers needed for the data separation.
- Default is a "trashbin" domain where all records with failed domain lookup are stored; for that reason access to this domain should be restricted to people with high security clearence as it may contain data that would normally fall into a "Secret" domain
- MSP is a domain for the Managed Service Provider itself; this domain can contain Secure domain as a standard level of visibility
- Secure domain should contain sub-domains with all customers without special security requirements, customers where all MSP fulfillers can see the data; this group is usually the largest one, contains the highest number of sub-domains with customers
- EU Access is an example of a special security requirements, some companies may restrict data visibility to EU citizens only; domain visibility assignment can be automated based on the user's location
- Similar groups can be related to e.g. government customers where one NDA may grant access to may sub-domains with customers
- Secret should contain sub-domains with customers where access requires e.g. customer-specific NDA; this is the only domain where access is granted directly to customer domains
Target is to create the hierarchy in a way where 1 domain visibility grants access to many customers. This is achieved by groupping of customers based on the security restrictions instead of e.g. geographical location.
Customer Layer
Customer layer contains domains for individual customers. Eventhough 1 domain can be used by many customers, it is recommended to have dedicated domain for every customer. This is recommended from the practical experience because security demands of the customer may change. If customer has dedicated domain, you can simply change the domain's parent to apply proper security restrictions. Moving all customer data from shared domain into a dedicated domain requires a lot of effort and testing.
You can change the domain hierarchy at any time but be careful with this operation. When you change the domain hierarchy, it must be updated in the whole database. And before it is updated, there is a mismatch between domains - domain paths used in database queries - of some records. User can be already updated into a correct domain path while tickets are still waiting for the update. Data visibility is inconsistent until entire domain is recalculated and updated.
Conclusion
Plan your domain hierarchy carefuly. Eventhough it can be changed, it may be very painfull excercise to do it. Well designed domain separation is better than quickly implemented one!
