'Understanding Domain Separation - Basics' (KB0715934) covers basic domain separation concepts and how domain separation works within the platform. This article will dive deeper and look at how domain separation can be configured on an instance and managed. Here we will understand how the system is configured to allow for domain separation, and then look at how customers can configure domain separation to work on their instance.
We saw in KB0715934 that data separation happens at the database level by adding the sys_domain column to data tables. When a user logs into a domain, the system builds queries in the background in order to find and retrieve the data from the database for that domain and all its children. The data then displays in the selected domain-separated table.
In order to find and retrieve data for a domain, SQL uses the “domain path” query method which relies on the values of the sys_domain_path. This query is supported through the glide.sys.domain.provider property.
To enable the domain path query method to work, there are two extra columns in the Domain table called Domain Code and Domain Path. Domain-separated tables have the Domain Path column, in addition to the ‘sys_domain’ column. Process-separated tables have both these columns plus the sys_overrides column.
A Domain code is a system generated series of 3 character codes corresponding to a specific domain record, and a domain path is this code prefixed with the immediate parent’s paths domain codes separated by a slash. The sys_domain_path value is unique in the Domain table. To find data for a particular domain, the system runs queries using that domain path value. Using Domain Paths, queries are generated automatically from the domain and these queries are always being re-calculated.
For example, suppose a user is logged into an instance and their user profile record is assigned to the INITECH domain. When the Task table is accessed, the system builds a domain path query in the background in order to filter and pull the data from INITECH domain and all of the child domains under it in the hierarchy. The query is essentially telling the system, 'Select all tasks where the domain path starts with "!!!/!!#/!!!/" ' The system then searches for all records in the domain and subdomains to populate the Task table.
Here is an illustration of domain hierarchy and associated paths.
A domain path can have a maximum of 255 characters. The system accommodates 216,000 domains per level, and 63 levels deep in a hierarchy, however maxing out on these system limits could have performance implications.
In order for domain paths to work, the value of a domain path in a domain-separated table must match its path value that is listed in the Domain (system) table. When domains are configured, the system configures the paths and populates the domain paths in domain separated tables based on the domain path value in the system domain table.
Under certain scenarios, domain path issues can arise when a record is created in a separate domain than the domain of the currently logged in user, causing the system to put the wrong domain path in the record. Domain path errors can also arise when users manually change the domain paths or the path does not get populated correctly, for example if the domain separated table's data was imported from another instance where the domain paths were different or even the domain table data.
To facilitate correction of domain path issues, the system provides Domain Validation where a validation job can be run to check for errors in the sys_domain paths. This ensures that the sys_domain paths point to the right place and keeps the domain sys_domain_path stored in the domain separated tables in sync with the domain table's sys_domain_path.
Domain Validation on an instance can be accessed from the Domain Configuration page.
In previous versions of ServiceNow, a resource-intensive nightly validation job was run to fix errors in domain paths.
Starting with Kingston, the functionality of this nightly job was significantly reduced, where the nightly job only checks the consistency of the domain table, and for the presence of the sys_domain_path in all domain-enabled tables.
In Kingston and later releases, actual domain validation and fixing of domain errors can now only be run on demand by customers from the Domain Configuration page.
IMPACT: Domain hierarchy validation might take an excessive amount of time if there are a large number of records in a table. Run this when needed during off-business hours for minimal performance impact.
When the domain hierarchy changes, new paths will be computed and the changed domain path values are propagated everywhere in the system within tables that are domain separated.
For example, if we delete a domain in the hierarchy, the system automatically re-parents the child domains of the deleted domain to its parent. However the domain admin has the option to re-configure the child domains as desired. When the domains are re-configured within the hierarchy this way, the domain paths will be automatically recalculated and the system also updates all records so that they point to the right domain.
There are scenarios where domain paths may not always be in sync between the main domain table and the domain-separated tables. Domain validation becomes especially important when the domain hierarchy changes in any way.
Domain Scope: Session Scope versus Record Scope
In addition to domain paths, another way the system can be configured to limit visibility to records is through domain scoping.
Every user has two domain scopes when establishing a session in a domain-separated instance: The session scope is set to the domain listed in the user's user record, but a user can manually change their session domain scope using the domain picker when logging in. Record scope uses the domain of the record and is active when viewing the form of any record. Visibility into different records and forms is determined by record scope and session scope. By default, the record scope takes precedence over the session scope.
Users with the domain_expand_scope role can change the domain scope using the Toggle Domain Scope UI action on a data form. When record scope is in effect, click the UI Action to switch to session scope and display all data available based on the user’s domain and child domains.
When session scope is in effect, click the UI action to change to record scope and display only data that matches the current record’s domain.
Domain Separation - System Properties
- glide sys.domain.use_record_domain_for_processes (true/false) - controls the domain used when selecting processes. When this property is enabled, system will use the record's domain for choosing which processes to run on any form. For lists, system will use the user's session domain for picking the processes.
- glide.sys.domain.use_record_domain_for_data (true/false) - controls the domain used when selecting data. When this property is enabled, system uses the record's domain for restricting the data visibility within a form. Users with appropriate role will see Toggle Domain Scope UI Action to toggle domain scope between record's domain and user's session domain.
NOTE: When either the glide.sys.domain.use_record_domain_for_processes or glide.sys.domain.use_record_domain_for_data property is set to TRUE, the following properties are not used, regardless of their setting:
- glide.ui.domain_reference_picker.enabled (true/false) property enables the type ahead reference domain picker.
- glide.ui.domain_picker.role By default, users with the itil role, and roles that include the itil role can access the domain picker in UI16. You can restrict roles that have access to the domain picker by setting the roles as a coma separated list of roles in this system property.
Domain Process Override
- glide.domain.strict_override (true/false) property prevents a child domain from inheriting the processes from the parent, even if they have not created overrides. When this property is ON, the domain framework will enforce stricter rules for policy overrides. For example, when a module is overridden in a child domain and marked as inactive, it will NOT use the parent domain's module when the property is ON.
Or for example, if we are in Domain B and we don’t want any processes from the parent Domain A. If have not overridden the rules from Domain A and have not created any business rules in Domain B, the system will run the business rules from parent Domain A as long as this property is False. But if this property is enabled, Domain B will not get any business rules from parent Domain A.
- glide.sys.restrict_global_domain_processes (true/false) property set to true, by default, when a user in the Global domain and views a table containing a sys_overrides column, the user sees records from only the global domain. This property enables an admin user to expand visibility from just the global domain to all domains. The Expand/Collapse Domain Scope links are used to expand or collapse visibility when this property is enabled.
- glide.sys.domain.skip_domain_insert_businessrules (true/false) Specifies the domain scope for business rules executed on the domain table. In new activations of domain separation, the property default is true and business rules are determined by the session domain. In existing implementations, the property default is false and the business rules are determined by the newly created domain’s hierarchy
Domain Separation - User Preferences
- glide.domain.session_scope (true/false) sets the default to session scope. When true, sets the default scope to the user's session domain rather than the record's domain. When false, the default scope is the record's domain. Users with the domain_expand_scope user role can still change the domain scope as needed.
- glide.domain.session_scope_notification (true/false) When true, displays a visual cue that record values include an expanded domain scope. When false, this notification is hidden.
- KB0715934: Understanding Domain Separation - Basics
- Understanding Domain Separation
- Visibility and Contains Domains
- Create contains relationships between domains
- Change domain visibility
- Domain separation setup and basic administration
- Delegated administration
- Troubleshoot domain separation errors
- Enable verbose domain logging and debug messages
- Application support for domain separation