Domain separation explained

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

    Domain separation in ServiceNow allows you to segregate application data, user interface (UI), and business logic within a single customer instance. This segregation supports hierarchical tenant models, enabling service providers to securely and efficiently manage multiple tenants on one platform. While some global elements like system properties and table schemas remain shared, domain separation ensures that tenants access only their permitted data and customized UI and business logic tailored to their domain.

    Show full answer Show less

    Key Features

    • Data Separation: Tenants see only data they’re authorized to access. Updates to records in separated domains do not generate Update Set records. User access is confined to their domain and permitted domains, ensuring data privacy and security.
    • UI Separation: Allows customization of UI elements such as views, lists, labels, menus, forms, and dashboards for specific domains. This enables tailored branding and user experiences per tenant without affecting core process logic.
    • Business Logic Separation: Supports tenant-specific system policies including email notifications, business rules, client scripts, UI policies, and UI actions. Parent-child hierarchical modeling ensures parent tenant logic executes for child tenants, with options to override at child levels.
    • Hierarchical Modeling and Cross-Tenant Intelligence: Tenants are nested in a hierarchy allowing parent tenants to access child tenant resources. The platform automatically manages data, metadata, and processing context across tenants with cross-tenant access.

    Key Outcomes

    • Improved Security and Compliance: Data and process segregation prevent unauthorized data access and enable strict governance across tenants.
    • Enhanced Efficiency: Centralized administration combined with tenant-specific customizations reduces overhead while maintaining consistent core processes.
    • Scalability for Service Providers: Enables multitenant instance architectures that efficiently deliver offerings to multiple customers with distinct requirements.
    • Customizable Tenant Experiences: Allows service providers to tailor UI and business logic to meet unique customer needs without compromising the overall platform stability.

    Practical Considerations

    Implementing domain separation incurs management overhead, so proper planning is essential. Some system-wide properties cannot be separated per tenant. Understanding domain assignments, hierarchical structures, and query behaviors is critical for effective configuration. ServiceNow provides tools such as domain pickers and logging to support setup and troubleshooting. Domain separation integrates with plugins like Customer Service Management (CSM) and requires awareness of performance and governance impacts.

    With domain separation, you can segregate application data, UI, and business logic, such as rules or workflows, in a single customer instance. Separating these elements into logically defined domains supports specific hierarchies for all customers using your applications.

    Domain basics

    Domain separation, also known as ServiceNow multitenant platform architecture, adds considerable overhead to the management of an instance. If you use domain separation correctly though, it can improve efficiency, add greater security, and increase the performance of your customers' instances.

    You can't separate some global standards and properties, such as system properties and table schema, per tenant.

    Before you start separating domains, read the following guidelines.

    What you can do with domain separation

    • Data separation: Enables tenants of the domain to see only data that they have permissions to see. Tenants can be granted access to other tenant data but can't query tenant data that they don't have access to.
      • When you update data records, they do not generate Update Set records.
      • Users, including the customer accounts that are used for integrations, see only the data in the domains they have permission to access.
      • Customers, agents, and fulfillers see data that pertains to the customers and organizations that they support.
    • UI separation: Supports a tenant-specific experience for UI elements such as views, lists, labels, and so on.
      • You can override the browser-based user interface, including application menus, lists, forms, and dashboards. You can also customize them for a specific domain or set of domains while preserving your basic process logic.
      • Service providers can alter the displayed branding and UI elements to meet individual customer needs.
    • Business logic separation: Creates tenant-specific system policies such as email notifications, business rules, client scripts, UI policy, and UI actions.
    • Hierarchical modeling: Nests your multiple tenants so that parent tenants can access child tenant resources. Business logic for parent tenants runs automatically for child tenants, which you can override at any level.
    • Cross-tenant intelligence: Automatically handles data, metadata, business logic, and processing context for tenants with access to additional tenant data.

    Domain separation at a glance

    The following graphic shows the division of data, process, and UI separation. These concepts are discussed in depth in the Recommended Practices section.

    Types of domain separation

    Domain architecture

    User records are assigned a domain value that represents the user’s home domain. Users have no access to data in parent domains, peer domains, or domains in other branches of the hierarchy.

    See Contains queries and domain access for advanced options to grant additional domain visibility.

    The following diagram shows how the architecture process flows down to the child domains. Process flows down Data rises up