Wiki home Community Training Support home Company home Demo

Domain Separation
Home > Administer > Security > Company and Domain Separation > Domain Separation

Contents
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
3 Delegated Administration
3.1 Determining the Domain Used for Delegated Administration
3.2 Example Delegated Administration with Domain Specific Policies
3.3 Example Delegated Administration with Domain Specific Applications and Modules
4 Domain Query Methods
4.1 Domain Paths
4.2 Legacy: Domain Numbering
5 Enhancements
5.1 Fuji
5.2 Eureka
5.3 Dublin

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: 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: 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:
Business rule
Module
Form template
Parent record
User who creates the record

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.
 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: 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: 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 The user can:
current record referenced in a field. 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 The user can:
domain of the current record referenced in See the reference field display value. For example,
a field. 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: Visibility controls what a particular user can see, while Contains controls what an entire domain
of users can see.

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
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
policy, application, or module at a higher level. 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.
 Note: When configured to use the record's domain instead of the user's domain, delegated
administration functions as described for Eureka for form loads and reference fields on those forms
only. If any transactions happen after the form load outside of reference field selections, the domain
reverts to the users 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:

Global domain rules

If David Loo updates the assignment rule for Database or Software, the following list appears:

Database domain-specific rules

The following policy changes occur:

When the policy is chosen and updated, the system detects that David Loo is not at the right level of
the hierarchy to change this record. Therefore, the update is changed into an insert, and a new record
is created.
The new policy has the same name (Database or Software). Notice that this policy is in the Database
domain and overrides the policy that previously applied (Database or Software).
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.
 Renamed Database or Software to Database Specific Policy

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.

Database Specific Policy assignment rule

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:
 Don Goodliffe's starting view of assignment rules

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:

Database San Diego rules override Database Specific Policy rules

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.

San Diego Specific Policy

 The result of the above customization is:

A database incident from the Database San Diego domain will be assigned to Don Goodliffe.
A database incident from the Database hierarchy other than Database San Diego will be assigned to
David Loo.
A database incident from any other domain, including global, will be assigned to the system
administrator.
The above customizations all show changes to higher-level policy. However, new policy can also be created
any 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.

Starting view of the Configuration application (excerpt)

David decides to rename the Configuration application to CMDB and to allow the inventory_admin role to see
the application.
 Sample domain-specific changes to the Configuration 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.

Sample domain-specific changes to the Open - "New" State module

This creates a new module entry in the application rather than overwriting the existing module in the global
domain.
 Domain-specific view of the Incident application

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.

David Loo's view of applications

 Fred Luddy's view of applications

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

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.

Category: Company and Domain Separation

Contents > Administer > Security > Company and Domain Separation

This page was last modified 17:31, 30 January 2015. This page has been accessed
77,962 times. Terms of Use