Thank you for your feedback.
Form temporarily unavailable. Please try again or contact docfeedback@servicenow.com to submit your comments.
Versions
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store
Close

Understanding domain separation

Understanding domain separation

Separate data, processes, and administrative tasks into logically defined domains.

Use domain separation to accomplish the following goals:

  • Enforce absolute data segregation between business entities.
  • Customize business process definitions and user interfaces for each domain.
  • Maintain some global processes and global reporting in a single instance.
  • Separate data between customers or sub-organizations.
  • Have minor or moderate process differences only among customers or sub-organizations.

Domain separation compared to separate instances

While the behavior offered with domain separation provides multi-tenancy support, multi-tenancy is still contained within a single instance. Some global properties, some global data, and some global processes are shared across all domains. For example, the option to have the system Remember me on the login page of the system is global and cannot be specified per domain.

If you need complete and total separation of all system properties and do not require global reporting or global processes, then separate instances is the best option.

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. The instance compares the domain of the user to the domain of the record, to determine what is visible. For example, consider the following domain hierarchy:

Figure 1. Example of 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.

Users in the global domain can see all records, regardless of the record's domain settings. Users are not able to see across domains or records at a higher level in the hierarchy.

Note: Guest users must be part of the global domain.
In general, data defined at a higher level in the domain hierarchy is not visible at lower levels in the hierarchy. However, the following records behave like policies:
  • Form sections
  • Options in a choice list

When defined at a higher level in the hierarchy, these records are visible in child domains.

Domain path migration

Domain paths are used for all customers. Domain numbering is not used. ServiceNow support can assist in the upgrade.

Alternatives to domain separation

Alternatives to domain separation include:
  • Before business rules
  • Access control list rules (ACLs)
  • Filters
  • Security on related record
  • Custom views
  • Form layouts
  • Notifications
  • UI action conditions
  • Advanced reference qualifiers
Warning: Before activating domain separation, consult your 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.

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 by adding a sys_domain field to the table's dictionary definition. By default, the system only domain separates platform and base system application tables where appropriate.

Warning: ServiceNow does not recommend domain separating platform tables (any table with the sys_ prefix such as the Dictionary Entry [sys_dictionary] and Dictionary Entry Override [sys_dictionary_override] tables) as it can produce unexpected results.

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]

Assigning users to companies

Administrators can quickly assign users to a domain by assigning them to a company. After users are assigned to a domain, records automatically inherit the user's domain.

For example, assigning Bow Ruggeri to the ACME company automatically assigns him to the ACME domain. Assigning Don Goodliffe to the Initech company automatically assigns him to the Initech domain. Any records they create are automatically added to the appropriate domain.

Using business rules to assign domains

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 a sys_domain column available for the record's table.

Using modules to assign domains

Administrators can use the sysparm_domain URL parameter to automatically assign new records to a particular domain from a module. Administrators must create a module with an Argument value of: sysparm_domain=sys_ID of domain.

Using form templates to assign domains

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.

Domain inheritance on tables

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.

Automatic domain assignment based on user domains

If no other domain conditions apply, a record automatically inherits the domain of the user who creates it.

Control what users can see using Visibility domains and Contains domains

Visibility domains control what a specific user can see, while Contains domains control what an entire domain of users can see.

Visibility domains

Visibility domains is a related list on the user record that determines whether users from one domain can access records from another domain. Granting users a visibility domain grants all the rights they would normally have to the record based on ACL rule permissions.

A visibility domain:

  • Is a user-to-domain relationship and is explicitly granted.
  • Is not a child domain.
  • 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.

Contains domains

Use contains domains for more robust control. Normally parent-child relationships define the domain hierarchy. A contains domain lets you 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.

A contains domain:

  • Is a many-to-many, domain-to-domain relationship.
  • May have child domains. 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.

Contains domain example

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

Visibility domain example

Using domain visibility, 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 because of data separation.

Figure 2. Sample set of domain-separated incident records
Sample set of domain-separated incident records
Figure 3. Bow Ruggeri's incident list
Bow Ruggeri's incident list
Figure 4. Don Goodliffe's incident list
Don Goodliffe's incident list

You can add the database domain as a visibility domain to Bow Ruggeri's 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.

Figure 5. Bow Ruggeri's incident list with visibility domain
Bow Ruggeri's incident list with visibility domain

Inherit visibility domains based on group membership

If you set the domain table to the Group [sys_user_group] table, users can inherit visibility domains based on their group membership.

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.

Inherit visibility domains based on group membership

Domain scope

Domain scope defines what users can and cannot access.

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 users in higher level domains adhere to each record's data and process constraints. However, these users 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 does 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.

Record value selection 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.

Table 1. Record value selection
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.

Domains and associated companies

Domain separation lets you cascade changes you make to a company record to the domain and other records associated to the company.

By default, the system automatically assigns users to the same domain as their company. For example, all users of the ACME company automatically become members of the TOP/ACME domain.

Note: Users with the admin role can change their own user records and therefore can change domains. Managed Service Providers may want to either disable delegated administration or set up an approval process to verify that the user needs the admin role.

When you change a company's domain, the instance automatically changes the domain of the following associated records to match the company's new domain.

  • Locations
  • Departments
  • Groups
  • Users
Note: The instance does not automatically change the domain of any record where you have selected the Managed domain check box.

Domain deactivation and associated companies

When you deactivate a domain, the instance also automatically completes the following actions.

  • Deactivates all companies in the domain.
  • Prevents all users assigned to the inactive company from logging in.
Note: When a user from an inactive company attempts to log in, the user sees an error message.

For example, if you deactivate the ACME domain from the sample data, the instance also deactivates the ACME company, and the three sample users are locked out.

Figure 6. Login error message example

Domain scope properties and user preferences

Administrators have access to properties and user preferences that control domain scope.

Properties

New activations of domain separation automatically restrict domain scope to the record's domain for all processes. When the user views a record in a form, the record's related data (such as reference picker and related list data) and applied processes (such as business rules and client scripts) are restricted to the record's domain scope. If there are records in multiple tabs, each tab has its own domain scope based on the record opened within that tab. The following properties restrict domain scope to either the record’s domain and the user’s current session domain.

Table 2. Domain scope properties
Property Details
glide.sys.domain.use_record_domain_for_processes Restricts domain scope to the record's domain for all processes. This property does not apply to business rules. Business rules are always processed from the domain record.
  • Type: true | false
  • Default value: true
  • Location: System Property [sys_properties] table
glide.sys.domain.use_record_domain_for_data Restricts domain scope to the record's domain for all data.
  • Type: true | false
  • Default value: true in new domain activations
  • Location: System Property [sys_properties] table
When either the glide.sys.domain.use_record_domain_for_processes or the glide.sys.domain.use_record_domain_for_data property is set to true, the following properties are not used, regardless of their setting:
  • glide.sys.domain.use_record_domain
  • glide.sys.domain.use_record_domain_for_client_scripts
  • glide.sys.domain.domain_change_notify
  • glide.sys.domain.no_change_roles

Domain scope for business rules executed on the domain table

In new activations of domain separation, the session domain determines the business rules executed on the domain table. In previous versions, business rules executed on the domain table were set based on the newly created domain’s hierarchy. This behavior is modified by the glide.sys.domain.skip_domain_insert_businessrules property. Setting this property to true significantly improves domain insert performance.

Table 3. Domain scope properties for business rules executed on the domain table
Property Details
glide.sys.domain.skip_domain_insert_businessrules 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.
  • Type: true | false
  • Default value: true in new domain activations

User preferences

In addition, user administrators can set the following user preference globally or on a per-user basis:

Table 4. Domain scope user preferences
Preference Category Updated By Details
glide.domain.session_scope Domain Admin Only 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.
  • Type: true | false
  • Default value: false
glide.domain.session_scope_notification Domain Admin Only When true, displays a visual cue that record values include an expanded domain scope. When false, the notification is hidden.
  • Type: true | false
  • Default value: true

Domain query methods

A domain query method efficiently query large numbers of domains within an instance.

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:

Figure 7. An example domain tree
Table 5. Domain tree example
Domain name Parent domain Domain path
SNC None !!!/
SNC/US SNC !!!/!!!/
SNC/EU SNC !!!/!!#/
SND/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.

Installed with domain separation

Several platform components are added or modified with domain separation.

Roles

Role Description
domain_admin Can create, edit, and delete domains.

Additions to [sys_domain] fields

The sys_domain field is added to the following tables:

Table 6. Tables with the sys_domain field
Tables
sys_attachment
sys_user_has_role
sys_group_has_role
sys_email
sys_user_group
core_company
cmn_location
cmn_department
sys_gauge
sys_report
kb_feedback
sysapproval_approver
sys_user_grmember

Field for the Task Table

MSP Extensions add a task_for field to the Task table to support the New Ticket module. This reference field refers to the User table.

Figure 8. task_for column on the Task table

Options for the Group Type

MSP Extensions add several new default options to the type field of the Group table. Add to or update these types to support your domains.

Tables
Security
Support
Visibility

Business rules

Name Table Description
Domain - Activate/Deactivate core_company

If at least one of its companies is active, it activates the related domain.

If all related companies are inactive, it deactivates the related domain.

Domain - Cascade Company core_company Keeps a company's domain in synchronization with its users, groups, departments, and locations.
Domain - Cascade Domain - Email sys_email Keeps an email's domain in synchronization with its attachments.
Domain - Cascade Domain - Group sys_user_group Keeps a group's domain in synchronization with its inherited roles (sys_group_has_role records).
Domain - Cascade Domain - Knowledge kb_knowledge Keeps a knowledge article's domain in synchronization with its related feedback.
Domain - Cascade Domain - Task task Keeps the domain in synchronization with related tasks for wf_context, wf_executing, wf_history, attachments, emails, task_sla and its workflow, sysapproval_approver and its workflow, and sysapproval_group and its workflow.
Domain - Cascade Domain - User sys_user Keeps a user's domain in synchronization with its group membership (sys_user_grmember) and role (sys_user_has_role) records.
Domain - Cascade Domain - Version wf_workflow_version Keeps domains in synchronization with related workflow versions for wf_activity and wf_transition.
Domain - Deactivate Companies domain Deactivates related companies if a domain is deactivated.
Domain - Default - Task task Sets the task domain based on the Task for user's domain. If this domain would be global, sets domain to Default instead.
Domain - Default - User sys_user Sets a user's domain to Default rather than global.
Domain - Disallow Global Domain Record domain Prevents creation of a domain with the name global.
Domain - Override Copy sys_app_application When an application is overridden for a domain, create a copy of its modules for the new application.
Domain - Override Copy sys_data_policy2 When a data policy is overridden for a domain, create a copy of its data policy rules for the new data policy.
Domain - Override Copy sys_gauge When a gauge is overridden for a domain, create a copy of its gauge counts for the new gauge.
Domain - Override Copy sys_ui_action When a UI action is overridden for a domain, create a copy of its UI action views for the new UI action.
Domain - Override Copy sys_ui_list_control_embedded When an embedded list control is overridden for a domain, create a copy of its client and server scripts for the new embedded list control.
Domain - Override Copy sys_ui_policy When a UI policy is overridden for a domain, create a copy of its UI policy actions for the new UI policy.
Domain - Set Domain - Approvals sysapproval_approver Set the domain to the same as the record being approved.
Domain - Set Domain - Attachment sys_attachment Set the domain to the same as the parent record's domain.
Domain - Set Domain - CMDB_CI cmdb_ci Set a CI's domain to the same its company.
Domain - Set Domain - Department cmn_department Set a department's domain to that of its company.
Domain - Set Domain - Domain domain Set a domain's domain to itself.
Domain - Set Domain - Email sys_email Set the domain to that of the parent record's domain. An email's parent record is the record specified in the instance field.
Domain - Set Domain - Feedback kb_feedback Set a knowledge feedback's domain to that of its knowledge article.
Domain - Set Domain - Group sys_user_group Set a group's domain to that of its company.
Domain - Set Domain - Group Approvals sysapproval_group Set the domain based on that of the record being approved.
Domain - Set Domain - Group Role sys_group_has_role Set a group role's domain to that of its group.
Domain - Set Domain - Location cmn_location Set a location's domain to that of its company.
Domain - Set Domain - Task SLA task_sla Set a task SLA's domain to that of its task.
Domain - Set Domain - User sys_user Set a user's domain to that of its company.
Domain - Set Domain - User Role sys_user_has_role Set a user role's domain to that of its user.
Domain - Set Domain - WF Activity Hist wf_history Set the workflow activity history domain based on the parent workflow context's domain.
Domain - Set Domain - WF Context wf_context Set the workflow context domain to that of the referenced record's domain.
Domain - Set Domain - WF Exec Activity wf_executing Set the workflow executing activity domain to that of the parent workflow context's domain.
Domain - Set task for - Change change-request When converting a ticket to a change request, set the Requested by field to that of the ticket's Task for value.
Domain - Set task for - Incident incident When converting a ticket to an incident, set the Caller field to the ticket's Task for value.
Domain - Validate Default domain Ensure that only one domain has the Default check box selected.
Domain - Validate Primary domain Ensure that only one domain has the Primary check box selected.
Business Rules Installed with Domain Support Plugin
Change Domain Set sys_dictionary Sets the domain set to the current domain.
Domain support properties sys_properties Sets the system properties to match the domain query method (domain paths or domain numbering).

Client scripts

Client script Description
Domain - Set Company and Location (sys_script) Monitors the incident caller field for changes. If the company and location fields do not already have a value, the script adds this information from the caller record. If the company and location fields already have a value, the script retains the existing values.
Deactivated script
(BP) Set Location to User Monitors the incident location field and sets the location field to the caller's location.