Domain separation levels of support

  • Release version: Xanadu
  • Updated August 1, 2024
  • 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 levels of support

    Domain separation in ServiceNow is a framework designed to make applications aware of multiple customers (tenants) within a shared environment. It enables the segregation of data, business logic, and administration to ensure that each customer’s information and configurations remain isolated and secure. Selecting the appropriate domain separation level depends on your application’s business use cases and how customers and administrators interact with the application.

    Show full answer Show less

    Levels of Domain Separation Support

    • No support: The domain field may be present on tables, but no logic enforces separation. This level does not provide true domain separation.
    • Basic: Supports customer data management by ensuring data is routed to the correct domain. Business logic, UI, reports, and caching respect domain properties at runtime. Instance owners configure the application to operate across multiple tenants. Use case: Ensuring chat messages between service providers and customers display correctly per tenant.
    • Standard: Includes Basic features plus customer-specific process management. Service providers can create or modify processes per customer, supporting multiple tenants in a single instance. Instance owners configure minimum viable product (MVP) business logic and parameters for each tenant. Use case: Requiring specific validation or comments on record closure for one customer but not others.
    • Enhanced: Builds on Basic and Standard by allowing customers themselves to safely configure business logic through UI-based tools without impacting other tenants. Customers can adjust parameters such as impact, urgency, or priority within their domain. Use case: Customers managing their own configurations in a shared environment.
    • Effective domain: Some applications may support domain-separated use cases without fully using the domain framework, relying instead on alternative configurations. An asterisk () denotes this. Use case: Prior to full domain separation support, Service Catalog used user criteria to separate catalogs and items per tenant, achieving Standard-level functionality.

    Practical Considerations for ServiceNow Customers

    When designing or selecting applications, consider the domain separation level needed based on your customers’ requirements for data isolation, process customization, and self-service configuration. Proper use of domain separation:

    • Ensures security and data integrity across tenants within a shared instance.
    • Provides flexibility for service providers and customers to manage business logic and data independently.
    • Supports scalability by enabling multiple customers to coexist without interference.

    Next Steps

    Review your application’s business use cases and customer personas to determine which domain separation level fits best. Leverage ServiceNow’s domain separation best practices and reference materials to implement or evaluate your application’s capabilities. Use domain separation features and configurations to maintain clear tenant boundaries, improve security, and empower tenant-specific administration.

    Choose from three categories for domain separation of an application for your customers' organizations.

    Applications that support domain separation may support the separation of data and data routing only, have advanced business logic separation, or support tenant (customer) level administration of the application. These definitions delineate the support levels from the perspective of actual use cases and the people who implement them.

    Incremental ServiceNow support levels

    Domain separation support levels

    Level Type Summary
    No support
    • The domain field may exist on data tables, but no business logic exists to manage the data.
    • This level isn’t considered domain-separated.
    Basic Customer data management
    • Business logic: Ensures that data goes into the proper domain for the application’s service provider use cases.
    • In the application, user interface, cache keys, reporting, rollups, aggregations, and so on, all consider the properties of the domain at run time.
    • Your instance owners must be able to set up the application to function normally across multiple tenants.

    Use case: When a service provider uses chat to respond to a customer’s message, the client must be able to see the response.
    Standard Customer process management
    • Includes the Basic level
    • Business logic: Processes can be created or modified per customer by the service provider. The use cases reflect how the application is used by multiple service provider customers in a single instance.
    • Your instance owners must be able to configure minimum viable product (MVP) business logic and data parameters per customer for the specific application.

    Use case: Admin must be able to make comments required when a record closes for one customer, but not for another customer.
    Enhanced Customer self-managed configuration
    • Includes Basic and Standard levels
    • Enables service provider customers to modify business logic that is based on defined use cases. These configurations are UI-based and fail-safe so that configurations by one customer can’t affect another customer.
    • The instance customers must be able to configure MVP business logic and data parameters themselves.

    Use case: Customer of a shared environment must be able to make changes according to impact, urgency, or priority within a domain.
    Effective domain*

    In some cases, a platform feature or application may support service provider use cases even if the domain framework isn’t being used. The use cases must be detailed to support domain separation. An asterisk (*) after the support level indicates this kind of configuration.

    Use case: Before the New York release, Service Catalog had no domain support but the instance owners could configure separate catalogs and items for each tenant in a domain-separated instance by using user criteria. The result was that each tenant could use Service Catalog at a Standard level.

    To view all applications listed by their support level see Application support for domain separation.

    Summary

    Domain separation is a framework that you must use to make your applications aware of its customers.

    Consider the domain framework capabilities, your applications' business use cases, what the personas are, and how they use the application before you can use the framework to make your application supportable.