8 Best Practices for Supporting Domain Separation

[shruti_tyagi]

Domain separation is a way to separate data, processes, and administrative tasks into logically defined domains. It is best suited for Managed Service Providers (MSPs) or for companies that have a global presence with unique and varying business requirements for different parts of the world.

Before implementing domain separation, you need to carefully consider whether or not it is well suited for your organization's business requirements. Once domain separation is enabled, there is no simplified way to disable it. While it can be disabled by turning off some properties and applying some additional changes, the process of disabling it is not so clean. So surely determine whether or not it is the right approach for the organization before enabling it.

There can be several other alternatives to domain separation, such as before query business rules, ACLs to limit data visibility among users and groups, filters, form layout views, view rules to limit form view, and fields by users and groups.

In the next few sections, I will explain some best practices for admins to consider when supporting domain separation.

8 Best Practices for supporting domain separation

1. Performance Considerations

2. Domain Hierarchy

3. Domain logs
4. Default Domains
5. Contains and User/Group Visibility
6. Domain Query Method
7. Debug SQL
8. Contains and User/Group Visibility

1. Performance Considerations

Limit the number of domains

Admins have the ability to create as many domains as needed, but it is important to make sure unnecessary domains are not created on the instance. Why? Because everything comes with a price, and a large number of domains on the instance can cause a performance impact. For example, it can slow down the domain picker and hence slow down the overall user experience. Specifically, if you are loading domain picker on the header and have a large number of domains, the domain picker has to load all domains before giving the user control on their session. This could lead to an outage situation as the user is unable to access anything on the instance until the domain picker is done rendering its results.

Before creating new domains, check the domain hierarchy under Domain Admin --> Domain Map and make sure you actually need to create a new domain or existing Domain Hierarchy will work.

Use the UI16 Domain Picker

Domain Reference Picker available in UI16. With the reference picker, you are not loading all the domains all at once, but rather the domain will be searched as the user types into the domain picker. This will give better performance when the user logs in to the instance.

Enable the domain reference picker in UI16 by following the steps below:

1. Enter sys_properties.list in the application navigator.
2. Set the following property to true: glide.ui.domain_reference_picker.enabled
3. Refresh the browser.

Note: Don't ever upload a large number of domains via integration or import sets as it can bring down your instance.

2. Domain Hierarchy

Implement changes to the existing domain hierarchy only when absolutely needed. Unless there is a genuine need, it is not recommended to keep changing the domain hierarchy once it is created.

When you update the parent of a domain, the system will perform re-parenting of all the related domains that change the domain hierarchy. When the domain hierarchy is updated, the system triggers a cascade update on all domain aware tables for the records created on that domain. As a result, it is not just one table you are updating, but rather a large number of other tables in the backend too.

In light of the same reasons mentioned above, even if it is absolutely critical to change the domain hierarchy, never do a mass update. Imagine the number of queries the system has to run if a mass update is performed to change the domain hierarchy. Always do it in small batches, and before starting the next batch of domain updates, make sure DWR (Domain Work Request) records are processed.

How to track DWR records

• In the syslog_domain table, there is an information entry for DWR execution completed. Always look for this entry as it provides confirmation that DWR is completed.

• In domain_work_request, make sure all records are reached to State =3 (Processed). This table captures information when you do long operations like changing domain hierarchy.

3. Domain Logs

Always check domain logs for any errors or warnings. Domain logs are stored in the syslog_domain table. When the domain hierarchy is updated, the system triggers a scheduled job to recalculate the domain paths. The results of the job are captured in this domain logs table. The system also captures the logs in this table when the domain validator runs and domain paths get recalculated. Look for any errors and warnings in this table. If there are any errors encountered during domain path validation, that information will be stored in the syslog_domain table and, after reviewing this table, admins will need to take action to resolve these errors and re-run the domain path validator.

Here is an example:>

As you can see in this screenshot, 10 orphan records in the sys_ui_list table are detected. An admin needs to fix these records in order to run the domain path validator successfully. These are the kinds of details you can look for in domain logs. Check out this documentation on troubleshooting domain separation errors.

4. Default Domain

Always have one default domain set for the domain records on your instance. The default domain is the domain to which the system automatically assigns task and user records that are not already assigned to a domain. Create a default domain with the name Default to differentiate it from other domains and check the default checkbox. Here is how your default domain configuration will look like:

If you do not set a default domain, then new tasks and user records are placed in the global domain. Records in the global domain are visible from any domain, so users in any other domain can see data that they may otherwise should not see, since it is wrongly placed in the global domain due to domain misconfiguration. If you set the default domain, records that don't belong to any domain will be placed in the default domain and will not be visible to any user other than an admin. Admins will need to keep looking for records created in default domain, move them to the correct domain, and may also need to investigate why records are getting created in the default domain.

Ideally, you should ensure all records are created in their appropriate domains (no global/default domains). If records are getting created in default domain this is something admin will need to look and fix.

5. Contains and User/Group Visibility

You should not have too many domain contains and domain-visibility set up on the instance. Use of domains-contains or user/group visibility should be used in special cases and only when absolutely needed for situations where a user or a group needs to see the data from a domain that they don't have visibility to, and moving those users/group is not an option. Using a large number of domain contains/visibility generates queries with too many OR conditions, which are slow and impact performance.

Instead of using too many contain relationships, make sure you have set up your domain hierarchy correctly. Check out this query:

SELECT ... FROM task task0 ignore index(number) WHERE task0.`sys_class_name` = 'incident' AND (task0.`sys_domain_path` = '/' OR task0.`sys_domain_path` LIKE '!!$/!!(/%' OR task0.`sys_domain_path` LIKE '!!$/!!$/!!&/%') ORDER BY task0.`number` DESC limit 0,20     

This query is just for one contain relationship. If you have domain contains, a domain that is the parent of a number of other domains you will have many more OR condition like this. A best practice is to carefully create a Domain Map, and before moving the user to the domain, make sure the domain is appropriate for the user so that he/she will have all necessary visibility. Creating domain contains and user/group visibility for the domain should be exceptions and used only when absolutely needed.

6. Domain Query Method

Use domain paths instead of domain spooling (sys_domain) or domain numbering. Domain spooling and domain numbering are replaced by domain path. Queries using domain path are much faster than spooling/numbering.

Domain path is the default query method for instances that had enabled domain separation recently, so you need not worry about it. It is the default for instances that enabled domain separation in Eureka and above.

However, if you are an older customer on domain separation and want to verify the query method on your instance, look for the following system properties:

• If domain path is enabled:
  In the System Properties table, you will see glide.sys.domain.provider=domain_paths and glide.sys.domain.paths.installed=true.
• If domain path is not enabled:
  Check the sys_properties table for these property values: glide.sys.domain.provider != domain_paths, glide.sys.domain.paths.installed=false

These properties will confirm the query method you are using.

Note: If you confirmed you are not using domain path query method, create a ticket with Customer Support and look for your options to switch to domain path

7. Debug SQL

Admins have the ability to perform debugging on the instance. If there is any slowness reported, enable SQL Debugging and look for any slow queries while you replicate the slowness. Another way to look for slow queries is to check the sys_query_pattern (slow queries) table by navigating to System Diagnostics > Stats > Slow Queries. This table stores slow queries in your instance.

In this table, you can search, for example, queries that contain domain_path to determine if there are any slow queries due to domain path in your instance. If you are able to find slow queries, try to analyze why the query is slow.

Common reasons for the cause of slow queries

• Too many OR Conditions (discussed in #5): In order to resolve this you will need to look at the domain hierarchy and see if you can place the user or a domain at a hierarchy level where contains/visibility will not be needed.
• Query method is not domain path (discussed in #6): If you are not using domain path query method, contact customer support.
• Query needs Indexing: If you are able to identify the slow query, run the explain plan and see if options for indexing are available.

Check out this blog by ankitkpal for details on improving queries using database indexing: Improve performance: database indexes and slow queries

8. Don't use domain path in scripts

Your script should not be dependent on the domain path. This is because, if at some point you have a requirement to change the domain hierarchy, the domain path will be recalculated and its value will change. Once this happens, your scripts will be useless or may throw errors. The best strategy is not to write your scripts on the basis of domain path. Always use the sys_domain field in your scripts to determine or evaluate the domain. Look for base system business rules which use the sys_domain field to get some ideas before creating your own scripts.

Additional resources for Domain Separation

• Application support for domain separation
• Request domain separation
• Validate domain hierarchy