| Note: This article applies to Fuji and earlier releases. For more current information, see Domain Separation at http://docs.servicenow.com
The ServiceNow Wiki is no longer being updated. Visit http://docs.servicenow.com for the latest product documentation.
- 1 Overview
- 2 Data Separation
- 2.1 Domain Assignment
- 2.1.1 Domain Separation Restrictions
- 2.1.2 Assigning New Records to a Domain from a Business Rule
- 2.1.3 Assigning New Records to a Domain from a Module
- 2.1.4 Assigning New Records to a Domain from a Form Template
- 2.1.5 Assigning Related Records to a Domain Based on the Parent Record
- 2.1.6 Assigning Records to a Domain Based on the User's Domain
- 2.2 Domains Visible to Users in the Global Domain
- 2.3 Visibility Domains
- 2.4 Domain Scope
- 2.5 Selecting Record Values from Other Domains
- 2.6 Contains Domains
- 2.1 Domain Assignment
- 3 Delegated Administration
- 4 Domain Query Methods
- 5 Enhancements
Domain separation is a way to separate data into (and optionally to separate administration by) logically-defined domains. Domain separation is best for those customers who need to:
- Enforce absolute data segregation between business entities (data separation).
- Customize business process definitions and user interfaces for each domain (delegated administration).
- Maintain some global processes and global reporting in a single instance of ServiceNow.
Domain separation is extremely well-suited for Managed Service Providers (MSPs) and global enterprises with unique business requirements in various areas of the world. Domain separation replaces Company Separation.
|Warning: Before activating domain separation, consult your ServiceNow representative to verify that it is suitable for your environment. Domain separation adds a level of administration overhead. Although it can be disabled, it cannot be removed from an instance.|
2 Data Separation
Members of a domain only see the data contained within their domain or the child domains that are lower in the domain hierarchy. By default, all users and all records are members of the global domain unless an administrator assigns them to a particular domain. Once you assign a user or a record to a domain, the instance compares the user's domain to the record's domain to determine whether the user can view the record. For example, consider the following domain hierarchy:
In this domain hierarchy:
- Bow Ruggeri can see any records in the Database Atlanta or the global domain.
- Don Goodliffe can see any records in the Database San Diego or the global domain.
- David Loo can see any records in the NY DB or the global domain.
- Fred Luddy, ITIL User, Beth Anglin can see any records in the Database, Database Atlanta, Database San Diego, NY DB, or the global domain.
|Note: Users in the global domain can see all records, regardless of the record's domain settings. If a user is a member of another domain, then there is no single visibility setting that allows users to see across domains or allows users to see records at a higher level in the hierarchy. See Visibility Domains to change what domains a user can view.|
|Warning: Guest users must be part of the global domain.|
2.1 Domain Assignment
By default, domain separation adds a domain field to the Task [task] and Configuration Item [cmdb_ci] tables and their extensions. You can also extend domain separation to any new tables you create by adding a sys_domain field to the table's dictionary definition. The tables provided with the ServiceNow system are domain separated where appropriate.
| Note: SeviceNow does not recommend domain separating platform tables such as the Dictionary Entry [sys_dictionary] and Dictionary Entry Override [sys_dictionary_override] tables because doing so can produce unexpected results.
The value of the sys_domain field contains the domain assigned to the record by any of the following:
2.1.1 Domain Separation Restrictions
Starting with the Fuji Release, the system prevents the following tables from being domain separated :
- Access Control [sys_security_acl]
- Script Include [sys_script_include]
- System Property [sys_properties]
- Security Black/Whitelist Entities [sys_security_restricted_list]
- Dictionary Entry [sys_dictionary]
- Dictionary Entry Override [sys_dictionary_override]
It is recommended that administrators do not domain separate these tables for versions prior to the Fuji release.
2.1.2 Assigning New Records to a Domain from a Business Rule
Administrators can use a business rule to automatically set a domain value when creating a record. The business rule must set a value in the sys_domain field. Administrators must ensure there is sys_domain column available for the record's table.
2.1.3 Assigning New Records to a Domain from a Module
Administrators can use the sysparm_domain URL parameter to automatically assign new records to a particular domain from a module. Administrators must create a new module with an Argument value of: sysparm_domain=sys_ID of domain. The sysparm_domain URL parameter is available starting with the Eureka release.
2.1.4 Assigning New Records to a Domain from a Form Template
Administrators can use a form template to automatically assign new records to a particular domain. Administrators must add the sys_domain field to the form and select a domain value. For example, setting the sys_domain field to TOP/ACME domain automatically assigns all records from this template to the TOP/ACME domain. Setting a domain from a form template is available starting with the Eureka release.
2.1.5 Assigning Related Records to a Domain Based on the Parent Record
By default, related records inherit the domain of the parent record. For example:
- A change task record inherits the domain of the parent change request record.
- A problem record inherits the domain of the parent incident record.
Related records inheriting the domain of the parent record is available starting with the Eureka release.
2.1.6 Assigning Records to a Domain Based on the User's Domain
If no other domain conditions apply, a record automatically inherits the domain of the user who creates it.
2.2 Domains Visible to Users in the Global Domain
By default, when a user in the global domain views a table containing a sys_overrides column, the user sees records from only the global domain. To view records from all domains, click Expand Scope under Related Links. To return to viewing records from the global domain only, click Collapse Scope. This feature is available starting with the Eureka release. This feature is enabled when the glide.sys.restrict_global_domain_processes property is set to true. If you are upgrading to Eureka, you can add this property.
These links are named Expand Domain Scope and Collapse Domain Scope starting with the Fuji Release.
2.3 Visibility Domains
Domain visibility determines whether users from one domain can access records from another domain. For example, if Don Goodliffe is in the Database domain, and Bow Ruggeri is in the Network domain, and no incidents are in the global domain, then Don Goodliffe cannot access Bow Ruggeri's incidents since data separation prevents this.
|Note: While visibility is one method to allow users to access records, it is recommended that you use Contains for more robust control. For more information on using Contains, see the Contains Domains section.|
You can add the Database domain as a Visibility Domain to the Bow Ruggeri's user record (Visibility Domains is a related list on the user record). Then, Bow Ruggeri can access Don Goodliffe's incidents since he now has visibility to the Database domain. If you remove the visibility domain, then Bow Ruggeri can no longer access incidents in the Database domain.
|Note: Granting users a visibility domain grants them all the rights they would normally have to the record based on ACL rule permissions.|
Users can also inherit visibility domains based on their group membership if you set the domain table to the Group [sys_user_group] table. For example, as a member of the Database group, Don Goodliffe also automatically gains the Database domain as a visibility domain. Group membership grants visibility to any matching domain name.
2.4 Domain Scope
Every user has two domain scopes when establishing a session in a domain separated instance.
- Session scope: is set upon session establishment to the domain listed in the user's user record. Users can manually change their session domain scope from the domain picker.
- Record scope: uses the domain of the record and is active when viewing the form of any record.
By default, the record scope takes precedence over the session scope so that fulfillers in higher level domains adhere to each record's data and process constraints. However, these fulfillers can choose to expand or collapse the domain scope to show or hide data from other domains. For example, a user in the MSP domain also has visibility into child domains such as the ACME domain. When looking at an incident record from the ACME domain, the user can choose to expand the domain scope to show values from the MSP domain or collapse the domain scope to only show record values that match the record's ACME domain.
|Note: Users always have access to data from domains that have been explicitly granted to them by domain visibility.|
Users with the domain_expand_scope user role can select the domain scope from the Toggle Domain Scope UI action on the form. When record scope is in effect, click the UI action to expand to session scope and display all data available based to the user's domain and child domains. When session scope is in effect, click the UI action to collapse to record scope and display only data that matches the current record's domain.
|Note: A record will not display the UI action to toggle the domain scope if the record is in the global domain or if the user's domain matches the record's domain.|
The option to select the domain scope is available starting with the Fuji release.
2.5 Selecting Record Values from Other Domains
Users who can see multiple domains have the option to select record values from a domain that is different than the record's domain. For example, service desk agents working for a managed service provider might want to assign certain incidents to themselves to resolve issues on behalf of their customers. When they do this, the incident Assigned to field might contain a user from the MSP domain, even though the incident record itself is associated with a child domain such as ACME.
Selecting a record value from another domain does not change the record's domain. The record retains its original domain. When a user views a record with values from multiple domains, the user's domain visibility determines what they see.
|When these conditions are met||The user has access to these UI elements|
|The user has access to the domain of the current record referenced in a field.|| The user can:
|The user does not have access to the domain of the current record referenced in a field.|| The user can:
The option to select values from visibility domains is available starting with the Fuji release.
2.6 Contains Domains
Normally parent-child relationships define the domain hierarchy. A Contains domain allows you to relate domains on an as-needed basis, independent of parent-child relationships. However, contains domains only grant visibility to domain data. Processes remain unaffected by contains relationships.
|Note: Visibility controls what a particular user can see, while Contains controls what an entire domain of users can see.|
2.6.1 Contains Domains Versus Visibility Domains
Contains domains and visibility domains differ in several respects.
A contains domain:
- Is a many-to-many, domain-to-domain relationship.
- Is hierarchical. When a domain is selected, you can see the data from that domain and its children.
- Is controlled by the selection in the domain picker.
A visibility domain:
- Is a user-to-domain relationship and is explicitly granted.
- Is not hierarchical.
- Is not controlled by the selection in the domain picker. Once the user is granted access to a visibility domain, they always see data in that domain and its children.
For example, there is a user who has access to domain A (the user's home domain) and is granted visibility to domains B and C. The user selects domain A in the domain picker. In this case, the user has access to domains A, B, and C. If the user changes the domain picker to domain B, B and C are visible. C is still visible because the user still has visibility to it. A is not visible, because it is not selected in the domain picker and it is not a visibility domain.
Using visibility domains excessively is not recommended.
3 Delegated Administration
Delegated administration allows administrators to set domain-specific policies. The policies set lower in the domain hierarchy override policies set higher in the domain hierarchy. While in a domain, administrators can set domain-specific versions of these global policies and settings:
- Client scripts
- System policies
- Application and module names
- Application roles
- Module filters
|Warning: All users with the admin role have special access to all system features, functions, and data because administrators can override ACL rules and pass all role checks. Grant this privilege carefully.|
When users have the admin role, then all policies in the instance are available to them regardless of the assigned domain. They can enter a specific domain, and then only policies in that domain or higher are visible and processed during a relevant transaction. When an administrator modifies a policy that is in a higher domain or the global domain, the system automatically creates a new record for that administrator's current domain. It does not modify the original policy, application, or module record. This new record overrides the original.
| Note: To make changes to a policy in a lower-level domain, go into that domain and modify the policy. This approach creates the new policy record in your domain that overrides the original, higher-level policy record.
Do not simply make changes on the higher-level policy and then change the Domain field on that policy. This approach does not create a new policy record in your lower-level domain, nor does it keep the policy record for the higher-level domain.
The sys_overrides field indicates that a policy, application, or module at a lower level in the hierarchy overrides a record at a higher level. The system automatically sets this field when an administrator attempts to modify a policy, application, or module belonging to another domain higher in the hierarchy. Again, rather than actually changing the higher level record, the attempted update is changed into an insert, and the sys_overrides field is set to indicate the higher level policy, application, or module that is being overridden. Later when the records for a relevant transaction are loaded, the overriding domain-specific policy, application, or module is used instead of the original.
3.1 Determining the Domain Used for Delegated Administration
By default, delegated administration always uses the record's domain to determine what policies to apply (starting with the Eureka release). The record's domain takes precedence over the user's domain. If there are no policies in the record's domain, delegated administration checks for policies in the next highest level of the domain hierarchy. The search for domain policies continues up the domain hierarchy until reaching the global domain. If there are no domain policies lower in the domain hierarchy, delegated administration uses the policies for the global domain.
For example, Fred Luddy is a user in the Database domain who can see records in the Database: Atlanta, Database: San Diego, and NY DB child domains. When he opens a record in the Database: San Diego domain, delegated administration first checks for policies in the Database: San Diego domain. If there are no policies at this level of the domain hierarchy, delegated administration checks for policies from the Database domain. If there are no policies in the Database domain, delegated administration uses the global domain polices as there are no other domains higher in the domain hierarchy.
|Click the plus for versions prior to Eureka|
In versions prior to Eureka, the user's domain determines what policies to apply unless configured to use the record's domain. The user's domain takes precedence over the record's domain. If there are no policies in the user's domain, delegated administration checks for policies in the next highest level of the domain hierarchy. The search for domain policies continues up the domain hierarchy until reaching the global domain. If there are no domain policies lower in the domain hierarchy, delegated administration uses the policies for the global domain.
3.2 Example Delegated Administration with Domain Specific Policies
|Click the plus to see example|
The following screens illustrate changing assignment rules at various levels of a domain hierarchy. In this hierarchy David Loo is in the Database domain and Don Goodliffe is in the Database/Database San Diego domain. To begin, David Loo makes a change to the global assignment policy. Then Don Goodliffe also makes a change to the same policy.
Initially, all assignment rules have a global domain as shown below:
If David Loo updates the assignment rule for Database or Software, the following list appears:
The following policy changes occur:
Notice that there are now two policy entries with the same name. Because this is not desirable, David opens the record and changes the name to something appropriate. After the update, the list appears as follows.
This time, the record being updated is at the same level in the domain hierarchy as the user, so the record is simply updated with a more appropriate name. Here is the resulting rule. Notice that database incidents will now be directly assigned to David.
If a new incident is created in the Database domain or lower in the hierarchy, the new rule is applied. It has overridden the global assignment rule. If a new incident is created in the global domain or any other domain not within the Database domain hierarchy, then the global rule applies.
In the following scenario, Don Goodliffe, in the Database/Database San Diego domain hierarchy, decides that database incidents created in his domain should be assigned to him rather than to David Loo. As an administrator, Don Goodliffe starts out with the following assignment policy:
Notice that this level of the hierarchy starts out with the policy established at the parent level (the Database domain). After changing the Database Specific Policy, the list look like this:
Again, the attempted update is changed automatically to an insert, and the override value is supplied to indicate that the higher-level policy is being overridden. Here is the resulting rule; it shows that database incidents created in the Database San Diego domain will be assigned to Don Goodliffe.
The result of the above customization is:
The above customizations all show changes to higher-level policy. However, new policy can also be created at any level of the domain hierarchy.
During a transaction, the current user's domain normally determines the policy to load. For example when a user in the Database domain updates an incident, the Database domain is used for business rules and policies even if the incident record was originally created in the Database San Diego domain. By default, the user's domain supersedes the record's domain.
There is a system setting that can change this behavior. If Using the Current Record's Domain Instead of the Current User's Domain is set to true, then the above behavior is reversed. The domain of the record is used to determine which policy to load, not the domain of the user. For example if a user in the Database domain updates an incident that is in the Database San Diego domain, then the business rules and policy that exist for Database San Diego are executed. The domain of the user still determines the records that are visible to the user, and the domain of the user sets the domain for records that user creates, but is not a factor in determining rules and policies.
3.3 Example Delegated Administration with Domain Specific Applications and Modules
|Click the plus to see example|
As the administrator of the Database domain, David Loo decides to customize the Configuration application. To start with, David reviews the modules available in the Configuration application module.
David decides to rename the Configuration application to CMDB and to allow the inventory_admin role to see the application.
Next, David decides to change the Incident application by activating the Open - in "New" State module and adding a new filter item to show open incidents in the Database category.
This creates a new module entry in the application rather than overwriting the existing module in the global domain.
If another administrator from another domain, such as Fred Luddy, logs in and looks at the Configuration application, he see the settings from the global domain.
4 Domain Query Methods
A domain query method allows the instance to efficiently query large numbers of domains. There are two domain query methods.
- Domain paths
- (Legacy) Domain numbers. Domain numbers are no longer supported starting with the (Eureka release).
Part of Domain Support 2.0 is a new query engine designed to perform and scale to tens of thousands of domains. Prior methods, including domain numbering, have had limitations that domain paths resolves. While you have the flexibility to continue using your existing query method, we highly recommend that you switch to domain paths through the new Domain Configuration screen at your earliest convenience.
4.1 Domain Paths
A domain path is a series of three-character codes separated by a slash (/) delimiter that uniquely identifies a domain. Each digit in the three-character code consists of one of the following 60 possible characters:
|Domain Name||Parent Domain||Domain Path|
|Note: With three-character codes delimited by a single character in a path string of 255 total characters, each node of the domain tree supports up to 216,000 child domains, and the maximum depth of the tree is 63 levels.|
4.2 Legacy: Domain Numbering
Domain numbering is a legacy query method that assigns simple decimal reference numbers to each domain. These numbers are easier to query than strings of long domain names. Customers whose networks include thousands of domains, such as managed service providers (MSP), used the domain numbering query method to improve the efficiency of database queries.
Domain numbering has been superseded by domain paths, which is even more efficient, consistent and scalable. ServiceNow recommends disabling domain numbering after you successfully test and validate the domain paths query method.
- Domain separation allows users who can see multiple domains the ability to select the domain scope and select record values from other domains without changing the record's domain.
- The domain reference pickers provide access to all domains that the user has access to, regardless of which domain the user is currently in.
- The property glide.domain.strict_override is available to force the system to show overridden records. When this property is set to true, records in the parent domain do not appear when an overridden copy of the records exist.
- The Domain Support - MSP Extensions plugin is named Domain Support - Domain Extensions.
- Users in the global domain can choose to view data from all domains or just the global domain.
- Administrators have additional options to assign records to domains.
- Delegated administration uses the record's domain when searching for policies.
- Two new properties are available to handle on-screen notifications that appear when the domain picker automatically changes based on which domain the user is currently in:
- glide.sys.domain.domain_change_notify: When enabled, a notification appears telling the user that the domain picker automatically changed. The default value is true after administrators add this property to the System Properties [sys_properties} table.
- glide.domain.notify_record_change: When enabled, a notification appears telling the user that the domain picker automatically changed because the record that the user is viewing changed the domain in which the user is in. The default value is false after administrators add this property to the System Properties [sys_properties} table.