Thank you for your feedback.
Form temporarily unavailable. Please try again or contact docfeedback@servicenow.com to submit your comments.

Domain separation for HR Service Delivery

Log in to subscribe to topics and get notified when content changes.

Domain separation for HR Service Delivery

The ServiceNow® HR Service Delivery application improves the employee service experience by automating HR interactions and providing a single platform for all HR services. Domain separation separates data, processes, and administrative tasks into logical groupings called domains. You can then control several aspects of this separation, including which users can see and access data.

Overview

Support: Data only

Domain separation in this application is supported at the Data only level, meaning it supports the data security model of separating visibility of data from one domain to another. To learn more, see Application support for domain separation.

Domain separation is best for customers who:
  • 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.
These users can choose to expand or collapse the domain scope to show or hide data from other domains. For example, vendor data from Vendor A can be separated from the vendor data of other vendors. Each vendor using the HR Service Delivery application can have separate data that cannot be shared with other vendors.
Note: Users always have access to data from domains that have been explicitly granted to them by domain visibility.

How domain separation works in HR Service Delivery

  • While HR Service Delivery supports separation of data, separation of logic and process is not fully supported.
  • When working in a domain-separated implementation, ensure that records are created at the right domain level so that it is visible to the right set of users.

    For example, domains that look like:

    • Global
      • TOP
        • Domain A
        • Domain B
    • For users to access an HR case in domains A and B, the HR case should be created at the global level. If the HR case is created in Domain B, you cannot access it in Domain A due to indexing.
    • For an HR case to be visible to users in TOP and Domain A, create the HR case in Domain A.
  • Unless the HR cases are in the Global domain, users should not assign HR cases in a higher domain to users in a lower domain. Users in Domains A or B do not have access to the control.

Use case: domain separation in HR Service Delivery

Vendor data for Vendor A can be separated from Vendor B. Each vendor using the HR Service Delivery application can have separate data that cannot be shared with other vendors.

By default, domain separation adds a domain field to the Task [task] and Configuration Items [cmdb_ci] tables and their extensions.

You can extend domain separation to any new tables you create by adding a sys_domain field to the dictionary table definition. By default, the system-only domain separates platform and baseline application tables where appropriate.
Warning: Do not domain-separate platform tables (sys_ prefix) or Dictionary Entry Override [sys_dictionary_override]tables. Doing so can produce unexpected results.

In this use case, client scripts, business rules, workflows, processes, and so on, can be domain-separated.

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 system’s “Remember me” option on the login page is global and cannot be specified per domain.

If a complete and total separation of all system properties is needed and does not require global reporting or global processes, separate instances are the best option.

Use case: domain separation in Lifecycle Events

Activity Sets set up in a parent domain and shared by children domains. For example:
  • Parent Domain:
    • P
  • Child domains:
    • Q
    • R

    When an Activity Set is created for the Parent Domain P, it is available to Q and R.

    Activity Sets that are created in Q and R are not available to P or each other.

To learn more about domain separation, see Understanding domain separation .

Feedback