---
sourceDocument: Australia Platform security
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/platform-security

 Release :

    - australia

ft:locale :

    - de-DE

ft:publication_title :

    - Australia Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Domain separation hierarchies

# Domain separation hierarchies {#ariaid-title1}

* Freigeben Version: Australia
* 
* Aktualisiert 12. März 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 Minuten Lesedauer

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

## Sample domain separation hierarchies {#bp-domain-sep-hierarchies__section_q3b_wjc_qhb}

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.  
  Hinweis:  
  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.
  {#bp-domain-sep-hierarchies__ul_xhh_ykc_qhb}
{#bp-domain-sep-hierarchies__ul_m51_pkc_qhb}

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.
{#bp-domain-sep-hierarchies__ul_v4n_14c_qhb}

## Domain hierarchies {#bp-domain-sep-hierarchies__section_pvw_gpw_qhb}

* 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.
  {#bp-domain-sep-hierarchies__ul_xfg_lmw_qhb}
* "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.
  {#bp-domain-sep-hierarchies__ul_amr_lmw_qhb}
* 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.  
    Hinweis:  
    Use sparingly, as Visibility can allow complete access that you may not intend.
  {#bp-domain-sep-hierarchies__ul_sqs_mmw_qhb}
{#bp-domain-sep-hierarchies__ul_chm_fmw_qhb}

## Basic principles of defining a domain hierarchy {#bp-domain-sep-hierarchies__section_m1r_kpw_qhb}

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.

   Hinweis:  
   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.
{#bp-domain-sep-hierarchies__ol_dhp_2wr_lrb}

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.
  {#bp-domain-sep-hierarchies__ul_w3g_tpw_qhb}
* 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.
  {#bp-domain-sep-hierarchies__ul_bfx_tvw_qhb}
{#bp-domain-sep-hierarchies__ul_rmd_4pw_qhb}  
Abbildung : 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.

To learn more about hierarchy architecture, see [Service provider reference architecture](https://servicenow-prod.fluidtopics.net/I7hvZlnhK2CMWNxs17Ur2w "Your customers can access service provider (SP) services by using a portal that is designed for them to reach their domain-separated instance.").
**Zugehörige Konzepte**   

* [Domain separation explained](https://servicenow-prod.fluidtopics.net/x9xyVWl9u0yhkSMd6PgbBw "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://servicenow-prod.fluidtopics.net/hSeeFgDzm2U__u_XsOCBsg "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://servicenow-prod.fluidtopics.net/yQ9RQVyEkZdMQEmVYhCGCw "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://servicenow-prod.fluidtopics.net/Lv2WmMnM3OxtInjuL8rlYw "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://servicenow-prod.fluidtopics.net/o~73HsH~C~Y8lCJBbqNjKA "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://servicenow-prod.fluidtopics.net/~rh2XIdcd8JY~l2bgFgr~Q "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://servicenow-prod.fluidtopics.net/dB~D65eJSYPmKEJYOgd2RQ "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://servicenow-prod.fluidtopics.net/P8ZuAavQomgk_~ZYZYkfyw "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://servicenow-prod.fluidtopics.net/~BeGlrS5mkBAZC8MgNeHNw "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://servicenow-prod.fluidtopics.net/hTDpifH47t2Gr1s9ep3duA "Check the domain logs to find errors or warnings in your domain path processes and hierarchy configurations.")
* [Importance of the Default domain](https://servicenow-prod.fluidtopics.net/s60j9ApH7YvVauD3Os2I4w "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://servicenow-prod.fluidtopics.net/z9rKyulEpro~zy87l2cNMg "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://servicenow-prod.fluidtopics.net/yWArrf6dWdJiSqzk7MV0rg "You can create effective queries with domain paths.")
* [Slow queries and SQL debugging](https://servicenow-prod.fluidtopics.net/MDCvsO1Iv3cuVtEHAH_bfg "Debugging SQL and slow queries can help you resolve slowness issues in an instance.")
* [Before Query business rules](https://servicenow-prod.fluidtopics.net/dYg_2l53Fdrn0m68dyF7wQ "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://servicenow-prod.fluidtopics.net/bv~55hFZ7r56GVb0sh0iDg "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://servicenow-prod.fluidtopics.net/Vo~HSBl~YXh~9ao1ckJZHw "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.")  
**Zugehörige Verweise**   

* [Segregating and securing data with domain separation](https://servicenow-prod.fluidtopics.net/XOxpsOY5MXa0uH9QRefifQ "You can segregate and secure data on the ServiceNow platform in multiple ways, depending on your customer's needs. ")
* [Alternatives to domain separation](https://servicenow-prod.fluidtopics.net/p_6ioFlafs3xFn~zvUKCyg "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://servicenow-prod.fluidtopics.net/4r7B5rm_p0mj2kqvK6uXug "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://servicenow-prod.fluidtopics.net/ILX1hP1qttb97unHeBSDJA "Domain separation may work better for your customers' organizations than any other method for separating the data between groups and departments.")
* [Domain separation levels of support](https://servicenow-prod.fluidtopics.net/UGOnrC3b1gBgenLDX_TxRQ "Choose from three categories for domain separation of an application for your customers' organizations.")
* [Service provider reference architecture](https://servicenow-prod.fluidtopics.net/I7hvZlnhK2CMWNxs17Ur2w "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://servicenow-prod.fluidtopics.net/H1gx~UAruHKGV3488YLtEg "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://servicenow-prod.fluidtopics.net/mcw9B6D7asbF5cb6Qw3jhg "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.")