Domain Separation

From ServiceNow Wiki
Jump to: navigation, search
Note
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

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
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:

Sample 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
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
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
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
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.


A sample set of domain separated incident records

Bow Ruggeri's incident list

Don Goodliffe's incident list

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.

Bow Ruggeri's incident list with visibility domain

Note
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.

Visibility domains granted by group membership

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
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
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:
  • See reference field display value. For example, sees the user name in the Assigned to field.
  • See the related record from reference icon. For example, sees the user record for the user in the Assigned to field.
  • Select values from any visible domain. For example, can select users from either the MSP and ACME domains.
The user does not have access to the domain of the current record referenced in a field. The user can:
  • See the reference field display value. For example, sees the user name in the Assigned to field.
  • Only select values from the record's domain. For example, can only select user's from the ACME domain.

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
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
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
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.

3.2 Example Delegated Administration with Domain Specific Policies

3.3 Example Delegated Administration with Domain Specific Applications and Modules

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:

!#$&()*+,-.0123456789:;<?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^`}|{~

The three-character codes that make up a path are not unique across a domain tree. Rather, the entire path string itself is unique. For example:
Domain paths.png

Domain Name Parent Domain Domain Path
SNC None  !!!/
SNC/US SNC  !!!/!!!/
SNC/EU SNC  !!!/!!#/
SNC/RU SNC  !!!/!!$/
SNC/US/NY SNC/US  !!!/!!!/!!#/
SNC/US/CA SNC/US  !!!/!!!/!!$/
SNC/EU/DE SNC/EU  !!!/!!#/!!!/
SNC/EU/FR SNC/EU  !!!/!!#/!!#/
Note
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.

5 Enhancements

5.1 Fuji

  • 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.

5.2 Eureka

5.3 Dublin

  • 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.
Was this article helpful?
Yes, I found what I needed
No, I need more assistance