---
sourceDocument: Brazil Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Domain separation levels of support

# Domain separation levels of support {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 is a critical framework in ServiceNow that enables applications to be aware of and effectively manage multiple customers (tenants) within a shared instance.
It ensures data segregation and appropriate business logic handling across different organizational domains, which is essential for service providers managing multi-tenant environments.
Choosing the correct level of domain separation support depends on your application's business use cases, the personas involved, and how the application is utilized.
Show full answer Show less  

## Domain Separation Support Levels

ServiceNow defines three incremental levels of domain separation support for applications, each aligned with specific customer needs and administrative capabilities:

* **No support:** Although a domain field may exist on tables, there is no business logic enforcing domain separation. This level does not qualify as domain-separated.
* **Basic (Customer data management):** Business logic ensures data is correctly routed to the appropriate domain. The application respects domain properties at runtime across UI, reporting, caching, and aggregations. Instance owners must configure the app to operate across multiple tenants. *Use case example:* Service provider chat responses are visible only to the correct customer.
* **Standard (Customer process management):** Includes Basic features plus the ability for instance owners to tailor business processes and data parameters per customer. This supports multi-tenant process differentiation within a single instance. *Use case example:* Admin can enforce different closing comment requirements per customer.
* **Enhanced (Customer self-managed configuration):** Builds on Basic and Standard levels by enabling customers themselves to safely modify business logic via UI configurations without impacting others. Customers can manage key business parameters independently. *Use case example:* Customers adjust incident priorities or urgencies within their domain.

An additional note on **Effective domain** indicates that some applications support domain-separated use cases even without explicitly using the domain framework, relying instead on configurations such as user criteria to segregate tenant data.

## Practical Considerations for ServiceNow Customers

* Evaluate your application's business requirements and the complexity of tenant-specific logic needed before selecting a domain separation level.
* Ensure your instance owners or customers have the appropriate permissions and tools to configure domain-aware business logic according to the selected support level.
* Understand that higher levels of domain separation provide more granular control but require more sophisticated configuration and management.
* Use the domain separation framework to secure and segregate data effectively, ensuring compliance and tenant isolation within shared environments.

## Related Concepts and Resources

ServiceNow offers extensive guidance on domain separation including:

* How domain separation works with database queries and custom tables
* Configuring domain properties, themes, and domain pickers
* Performance and troubleshooting best practices
* Integration with plugins such as Customer Service Management (CSM)
* Reference architectures and evaluation guides for implementing domain separation

These resources help ensure successful implementation and management of domain separation tailored to your organization's multi-tenant needs.  
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 {#bp-domain-levels__section_x5w_kd2_rhb}

{#bp-domain-levels__table_ucy_nd2_rhb__entry__3}

| 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. {#bp-domain-levels__ul_jzy_h22_rhb} |
| 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. {#bp-domain-levels__ul_gm3_222_rhb} 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. {#bp-domain-levels__ul_smv_j22_rhb} 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. {#bp-domain-levels__ul_bfg_422_rhb} 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. |
[ ]

{#bp-domain-levels__table_ucy_nd2_rhb} To view all applications listed by their support level see [Application support for domain separation](https://www.servicenow.com/docs/hWkSHmXhlD4~y5Abn6ejwg "Many ServiceNow applications support domain separation in the base system but not all. Some supported applications include limitations on the data and administrative settings that can be domain-separated. These definitions delineate the domain separation support levels from the perspective of actual use cases and the people who use them.").

## Summary {#bp-domain-levels__section_scg_lt3_skb}

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.
**Related concepts**   

* [Domain separation explained](https://www.servicenow.com/docs/hBKZ3Z6MizAlDbFkhnvGmA "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.")
* [Context and domain separation](https://www.servicenow.com/docs/zJgi4Nz7HoTVWQxYUBfw8A "The context of a user's session determines the processes, data, and user interface (UI) as the user browses through list views, home pages, reports, and knowledge articles. The context is determined by the processes that you create, the business rules that you set, your workflows, and other factors.")
* [How a database query works with domain separation](https://www.servicenow.com/docs/UeB3rTD~QffizO2DmFLRaA "Using database queries with domain separation in your customers' applications help them protect their data. These queries then speed up the configuration and build processes.")
* [Domain-separate a custom table](https://www.servicenow.com/docs/V5tzm7KYlIlaxXdt6qgoKA "You may need to create custom tables in separate domains. This topic covers both the procedure and the concept behind domain-separating a custom table.")
* [Customizing domain properties and themes](https://www.servicenow.com/docs/dMwGYqBz4U~nyDzYrCafXA "You can customize your customers' company properties and themes within the domains that you have configured. Customization makes their instances fit in with their companies' overall look and feel.")
* [Managing domain separation for specific uses](https://www.servicenow.com/docs/NLJmMxMOqbZBqQYd7soNbQ "You can set up separate domains for email notifications and customize the properties of catalog, tables, users, groups, and views. This enables you to provide more specific behavior in each domain, giving your customers more flexibility.")
* [Configuring domain separation with the domain picker](https://www.servicenow.com/docs/XNrLI30uaYfr_Un0WrdOKw "Use the domain picker wisely, and remember the 80/15/5 approach so that you do not customize too much and impact the performance of your instance.")
* [Domain separation performance considerations](https://www.servicenow.com/docs/GWFox6ez3UL41SBjr3b1ug "As you configure domain separation in your application and services, make sure that you consider the number and properties of domains you create. Too many property-heavy domains can impact the performance of your instance.")
* [Setting up domain hierarchies](https://www.servicenow.com/docs/~G76LdQpBw1LrjboAVDWIA "You can avoid slowdowns and performance impacts in your instance by knowing how domain hierarchies work and by setting them up properly.")
* [Checking domain logs for errors and warnings](https://www.servicenow.com/docs/vYynZZJxg7wHFlALEz0E0A "Check the domain logs to find errors or warnings in your domain path processes and hierarchy configurations.")
* [Importance of the Default domain](https://www.servicenow.com/docs/doGIHq6EdBS3mIoSn9MgQQ "Organizing your domains is a crucial part of the domain separation process. If you don't set a default domain, new tasks and user records go to the global domain. Anyone can see the records in the global domain, which means that data can be seen when it is not supposed to.")
* [Contains queries and domain access](https://www.servicenow.com/docs/OYZHXyzGPq2iZHHECtgC~A "Use a \"contains\" query only in special cases, such as when users or groups need to see data from a domain that they don't have access to, but you don't want to move those users to a domain. Creating domain \"contains\" and user or group access for a domain should be an exception, only when absolutely needed.")
* [Domain paths query method](https://www.servicenow.com/docs/jvjVPgCo6XCmd7w~9Tq0zg "You can create effective queries with domain paths.")
* [Slow queries and SQL debugging](https://www.servicenow.com/docs/_FfWCeDJnpK1t2S6pw81LQ "Debugging SQL and slow queries can help you resolve slowness issues in an instance.")
* [Before Query business rules](https://www.servicenow.com/docs/~gfO~YY0A4B2O_NgrBdouQ "You can use a Before Query business rule to help support data segregation on an instance. ServiceNow 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.")
* [Avoiding domain path in scripts](https://www.servicenow.com/docs/mOP0JjvRvag9jWx3fXppag "Domain paths can cause the values of your script to change or even break, so don't use them in scripts.")
* [Domain separation and the Customer Service Management (CSM) plugin](https://www.servicenow.com/docs/5YWAYxbHnBXvctpkuMu79g "For the best outcome, be aware of how the properties in the CSM plugin work. When the plugin is enabled, you can see the status of your records in your domains.")  
**Related reference**   

* [Domain separation hierarchies](https://www.servicenow.com/docs/C1o2z_5EE6SDqY6m1CIChg "Create a hierarchy when defining a domain architecture to track your processes and workflows.")
* [Segregating and securing data with domain separation](https://www.servicenow.com/docs/19vYzO2Bs~lEwuoxONG79g "You can segregate and secure data on the ServiceNow platform in multiple ways, depending on your customer's needs. ")
* [Alternatives to domain separation](https://www.servicenow.com/docs/tlOpJj7amOR0tSezthZqlA "You can use a separate instance as an alternative to domain separation for your customers. A separate instance allows you the flexibility to meet the requirements for data separation within the groups and departments in an organization with little to no impact on others.")
* [Evaluating the need for domain separation](https://www.servicenow.com/docs/8PZQ~u_af6IS07PBx3bRjw "You may find that domain separation doesn't always work for your customers' organizations. It's best that you base your decision to go with domain separation by looking at your customers' needs.")
* [Benefits of domain separation](https://www.servicenow.com/docs/1YJQG0wmEELpcWgBWxIhOA "Domain separation may work better for your customers' organizations than any other method for separating the data between groups and departments.")
* [Service provider reference architecture](https://www.servicenow.com/docs/ttllAc7JRr9sH_OIw3bZQQ "Your customers can access service provider (SP) services by using a portal that is designed for them to reach their domain-separated instance.")
* [Domain separation terms](https://www.servicenow.com/docs/_4ABFrdjgKOFlVuYw5PDkg "With a ServiceNow instance, you can improve efficiency, add greater security, and increase performance for your customer organizations. It's helpful to understand some of the most common terms as you create your configurations.")
* [Domain assignments](https://www.servicenow.com/docs/QL~7M4TL1jvd46TQCjS9Gw "How you assign a domain impacts the value of the sys_domain field. The assignments contain designs and business properties that affect how the application functions in each domain.")

