Domain Separation and HR Service Delivery

  • Release version: Zurich
  • Updated July 31, 2025
  • 3 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Domain Separation and HR Service Delivery

    The ServiceNow HR Service Delivery application enhances employee service by automating HR interactions within a single platform. It supportsbasic domain separation, which logically partitions data, processes, and administrative tasks into domains within one ServiceNow instance. This enables control over user access and data visibility across these domains, ensuring data segregation between different business entities or tenants.

    Show full answer Show less

    Basic domain separation means data and configurations are confined within specific domains, but hierarchical domain structures, sharing of data/configurations, and separation of logic or processes are not fully supported by default.

    Key Features

    • Data segregation: Each domain’s HR data remains isolated, preventing unauthorized access from other domains.
    • User access control: Users can view data only within their home domain and child domains, but not parent, peer, or unrelated domains, unless explicitly granted access.
    • Multi-tenant support: Enables service providers to manage cases or chats per tenant without exposing information to other tenants.
    • Global considerations: Some elements, such as shared agents and certain system properties, remain global and accessible across domains.
    • Data placement logic: Correct domain assignment for records is critical to ensure proper visibility and access by intended users.

    Practical Implications for ServiceNow Customers

    Domain separation in HR Service Delivery is ideal for organizations requiring strict data segregation between different business units or tenants while maintaining some global processes and reporting in a single instance.

    Customers should:

    • Ensure HR cases and records are created in the appropriate domain to control user access correctly.
    • Understand that process and logic separation are limited; complex multi-tenancy needs with full separation may require separate instances.
    • Leverage domain visibility and domain contains settings to manage cross-domain data access where necessary.
    • Recognize that some system-wide settings remain global and cannot be customized per domain.

    Key Outcomes

    • Improved data security and privacy by isolating HR data per domain in a multi-tenant environment.
    • Efficient handling of tenant-specific HR cases without cross-tenant data exposure.
    • Ability to maintain centralized HR service delivery while respecting organizational or tenant boundaries.
    • Clear guidance on setting up and managing domain separation to optimize HR Service Delivery operations within a single instance.

    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 is supported in HR Service Delivery.

    Domain separation separates data, processes, and administrative tasks into logical groupings called domains within a single ServiceNow instance. You can then control several aspects of this separation, including which users can see and access data.

    To learn more about domain separation, see:

    HR Service Delivery provides the basic level of domain separation support. Basic domain separation (data separation ) implies that if the data and all the related configurations reside within a particular domain, HR Service Delivery will function as expected. Hierarchical domain structure, sharing of data/configurations and logic/process separation is not supported by default in HR Service Delivery as per the basic domain separation definition.

    Support level: Basic

    Note:
    To learn more about support levels, see Domain separation levels of support.
    • There is business logic to ensure data goes into the proper domain for the application’s service provider use cases.
    • In the application, the user interface, cache keys, reporting, rollups, aggregations, and so on, all consider domain at run time.
    • The owner of the instance needs to be able to set up the application to function normally across multiple tenants.
    Use case: As a Service Provider organization, when I receive a case or a chat from a tenant in the system, I should be able to see and resolve that case without other tenant customers being aware of the case or process.

    Overview of HRSD 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, data from Company A can be separated from the data of Company B and Company C. Each domain using the HR Service Delivery application can have separate data that cannot be shared with other domains.
    Note:
    Based on the hierarchy, users can see data in their home domain and child domains of that home domain. Users will not have access to data in their parent domains, peer domains, or domains in other branches of the hierarchy. Users always have access to data from domains that have been explicitly granted to them by domain visibility and domain contains.

    Infographic explaining Domain Separation in HR Service Delivery

    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.
      Note:
    • 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
        Note:
        Global is not a domain.

        When agents are shared across domains, agents should reside in global and have access to the remote HR cases of all onboarded consumers.

      • For any user in Domain A or Domain B to access an HR case, the HR case must be created at an global level.
      • If an HR case is created in Domain A, a user from Domain B cannot access it. Likewise, if an HR case is created in Domain B, a user from Domain A cannot access it.
      • For an HR case to be visible to the users in TOP and Domain A, create the HR case in Domain A.
      • For an HR case to be visible to the users in TOP and Domain B, create the HR case in Domain B.

    Use case: Domain separation in HR Service Delivery

    While the behavior offered with domain separation provides multi-tenancy support, multi-tenancy is still contained within a single instance. A few properties, data and processes are always global and 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.