Domain separation hierarchies

  • Release version: Yokohama
  • Updated January 30, 2025
  • 4 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 hierarchies

    Domain separation hierarchies in ServiceNow enable instance owners to define structured domain architectures that help track processes, workflows, and data segregation effectively. These hierarchies organize domains into parent and child relationships, influencing process execution and data access within the instance.

    Show full answer Show less

    Key Features

    • Hierarchy Types:
      • Parent/Child: A process-driven hierarchy where parent domains can access all data in child domains.
      • "Contains" Domain: A data access hierarchy granting specific data rights without affecting processes; useful for managing data access for groups but can impact query performance with large datasets.
      • Visibility: Grants persistent data access visibility across domains regardless of record context; should be used sparingly due to potential broad access implications.
    • Default Domain:
      • Holds unassigned or "lost" data and users without a domain.
      • Only accessible by the service provider and never contains active users.
      • Ensures records do not unintentionally remain in the global domain, which is the absence of a domain on a record.
    • Domain Types for Access Control:
      • Restricted Domains: For customers requiring tightly regulated access with limited visibility.
      • Unrestricted Domains: For customers without stringent visibility constraints.
    • Global Domain: Represents records without any domain assignment and is accessible to all users unless restricted by security configurations.

    Practical Guidance for ServiceNow Customers

    • Design your domain hierarchy based on your business processes and data access needs, choosing between parent/child, contains, or visibility models.
    • Use the default domain to catch and triage orphaned data or users, preventing data loss in the global domain.
    • Avoid moving data between domains while the instance is in use to prevent data inconsistencies.
    • Segment customers into restricted and unrestricted domains to efficiently manage visibility and access, especially in multi-tenant environments.
    • Apply "contains" and "visibility" functions thoughtfully to balance access control and system performance.
    • Understand that global records have no domain and are accessible broadly unless restricted, so use domain separation to maintain data security and segregation.

    Key Outcomes

    • Effective domain separation hierarchies enable precise control over data access and process execution across different customer or organizational domains.
    • Proper use of default and global domains ensures that no data is unintentionally lost or exposed.
    • Segmenting customers into restricted and unrestricted domains simplifies administration and enforces security policies.
    • Awareness of domain hierarchy impacts on queries and performance helps maintain system efficiency.
    • By following these principles, ServiceNow customers can implement scalable, secure, and clear domain architectures that align with their multi-tenant or multi-unit organizational needs.

    Create a hierarchy when defining a domain architecture to track your processes and workflows.

    Sample domain separation hierarchies

    The following diagram is a good starting point for defining domain architecture. It demonstrates the relationship between the TOP and lower domains and how the process, data, and business rules impact parent and child domains.
    • In the following example, TOP is a process domain. It should never contain users. Rather, TOP should contain the new processes that instance owners develop and the overrides to these processes from the global domain.
    • Only the service provider (SP) has access to the default domain. This domain never contains active users. It contains only the "lost" data that you need to reassign to the correct domain.
      Note:
      When data is not assigned to a specific domain, it moves to the default domain. It is temporarily "lost" and needs to be assigned to its correct domain.
    • Tasks and users without a domain are placed in the default domain automatically when you create or update domains. You can override that action by either clearing the Default option on this record or selecting the Default option on another domain record. If you have not set a default domain yet, tasks and users with no domain move to the global domain.
      • Don't move data between domains while you are using the instance.
      • If any data ends up in the default domain, that means you have a configuration or procedural problem to address.

    You don't see the word "Global" in this diagram because there is no global domain. Remember that "global" is the absence of a domain on a record.

    For example, a table that has no domain field means that the table contains all global records. A table that has a domain field means that any record without a domain is a global domain.

    The word "global" is in the domain field. It is placed there automatically when the record has no domain.

    Global records are available to all users of the instance unless they are restricted by security configurations.
    • Use the default domain to make sure that records do not end up in the global domain on tables that should never have global records.
    • Instance owners must then triage the records in the default domain and move them to the correct domain.

    Sample domain separation hierarchies

    Domain hierarchies

    • Parent/child: Process and data affected
      • Design that is based on a process flow.
      • Remember that the parent domains can access all data in the child domains.
    • "Contains" domain: Only data is affected. For example, making SP in the diagram contain TOP does not make processes in SP run in the TOP domain and downward.
      • Grants data access rights to individuals in groups that require dedicated access to certain domains.
      • Contains causes or conditions to be added to database queries that can cause performance issues with large domain and data sets.
    • Visibility: Hierarchy that is always visible to users once you provide access. Only the data is affected, not the processes.
      • Grants data access of a domain to another domain that did not have that access when the parent-and-child hierarchy was built.
      • Enables users to see all the data in the domains that they have visibility access for, all the time, regardless of the record they are working on.
        Note:
        Use sparingly, as Visibility can allow complete access that you may not intend.

    Basic principles of defining a domain hierarchy

    Unrestricted and restricted use cases for domain separation.

    Many SPs have customers who implicitly state that access to their domains must be tightly regulated, which constrains the use of the “contains” function at the TOP domain. The following diagram explains how to mitigate that regulation by dividing domains into Restricted and Unrestricted domains.

    1. Customers exist in a specific "vertical" of the domain separation hierarchy. This means they only consume processes defined in their domain and all parent domains above theirs in the hierarchy. Any processes defined in domains that are not in their linear parent-child hierarchy do not apply.

      Note:
      Customers or "tenants" are entities that are segregated from each other completely, not like departments or business units that share resources with each other.
    2. Super verticals (restricted, manager services, and so on) are allowed as long as the customers only ever belong to one of them.
    3. Services, products, or offerings that need to be horizontally available to all customers are not defined within separate domain hierarchies.
    Domain hierarchy flow

    Domain hierarchy with verticals

    Here are some sample use cases:
    • Under TOP, you might create two domains, Unrestricted and Restricted.
      • Place customers and their domains that don't have SP visibility restraints under Unrestricted.
      • Place customers and their domains that do have that requirement under Restricted.
    • System admins can then use “contains” and “visibility” functions in an efficient, targeted manner.
      • Apply "contains" to Unrestricted, so a single “contains” can grant visibility to most customers.
      • Apply domain visibility using ”domain visibility groups” to specific domains as needed.
    Figure 1. Customer Decision Trees

    The following diagram delineates how to choose which hierarchy model is right for you. You can choose separate hierarchies, hybrid, or shared hierarchies depending on which processes and functionality you want in your domain structures.

    Customer decision tree
    Dedicated vs shared hierarchy of data separation

    To learn more about hierarchy architecture, see Service provider reference architecture.