---
sourceDocument: Brazil ServiceNow AI Platform Administration
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-administration
Release :
- brazil
ft:locale :
- en-US
ft:publication_title :
- Brazil ServiceNow AI Platform Administration
ft:clusterId :
- platadm
bundleId :
- platadm
workflow :
- Platform
---
# Building hierarchical queries
# Building hierarchical queries {#ariaid-title1}
Release version: Brazil
Updated September 10, 2026
 6 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 Building hierarchical queries
Building hierarchical queries in ServiceNow allows you to simplify and streamline data filtering by leveraging parent-child relationships within records.
Instead of complex multiple OR conditions, you can specify a single node in a hierarchy and query all related records underneath it.
This capability is especially useful when dealing with naturally nested data, such as departments, locations, or management chains.
Show full answer Show less
By default, ServiceNow includes predefined record hierarchies on the Department, Location, and User tables, each based on self-referential fields (e.g., Parent or Manager). These hierarchies are maintained automatically by the ServiceNow AI Platform, which generates hierarchical path data used for efficient querying.
## Key Features
* **Predefined Record Hierarchies:** Department, Location, and Manager hierarchies are included out-of-the-box, enabling immediate use for queries involving organizational, geographical, or reporting structures.
* **Hierarchical Paths:** Each record stores its hierarchy path, updated automatically, to support efficient searching within the condition builder.
* **Condition Builder Integration:** Hierarchical queries are created using operators like "is in hierarchy" and can include dynamic filters (e.g., "starting at \[Me\]") for personalized, context-aware queries.
* **Custom Record Hierarchies:** You can define new hierarchies on any table with self-referential fields by creating entries in the Record Hierarchy table, enabling hierarchical queries beyond the predefined sets.
## Use Cases and Practical Examples
* **Department Hierarchy:** Query assets linked to a department and all its sub-departments efficiently using hierarchical conditions, e.g., assets under the IT department and its subdivisions.
* **Location Hierarchy:** Search incidents based on caller location hierarchies, such as all incidents originating from Illinois and its cities, or dynamically based on the user's location.
* **Manager Hierarchy:** Find incidents assigned to a manager and their reporting chain or view user records in a management hierarchy, using both static and dynamic queries.
## Practical Steps to Build Your Own Hierarchy
* Identify a table with parent-child relationships using a self-referential reference field (e.g., Asset table with a Parent field).
* Create a new record hierarchy in the Record Hierarchy table specifying the target table and reference field.
* The ServiceNow AI Platform then generates and maintains hierarchy path data for records in that table.
* Use the condition builder to construct hierarchical queries based on your newly created hierarchy with appropriate operators.
Building and leveraging hierarchical queries improves query efficiency, reduces maintenance efforts, and enhances your ability to analyze data along natural organizational or structural lines within ServiceNow.
Simplify and build more efficient queries by leveraging hierarchical relationships in the condition builder.
## Key benefits {#data-hierarchies__section_cnk_rdf_bdc}
* Filter table data in the condition builder based on a record hierarchy.
* Search through an entire hierarchy with a single condition.
* Streamline query building with less ongoing maintenance.
{#data-hierarchies__ul_hkk_sdf_bdc}
Crafting queries in condition builder can become cumbersome when you need to search through each level of a hierarchical relationship using multiple OR conditions. Hierarchical queries streamline this process by allowing you to
specify a single node and search down the hierarchy from there, saving time and effort.
## Record hierarchies {#data-hierarchies__section_r5w_gfp_ngc}
By default, the following record hierarchies are included with your instance:
* The Department Hierarchy on the Department \[cmn_department\] table
* The Location Hierarchy on the Location \[cmn_location\] table
* The Manager Hierarchy on the User \[sys_user\] table
{#data-hierarchies__ul_dpx_cdp_ngc}
You can view these predefined record hierarchies by navigating to AllSystem DefinitionRecord hierarchy.
Each record hierarchy is based on a reference field that contains parent-child relationships between records in the same table.
* The Department Hierarchy is based on the Parent reference field in the Department \[cmn_department\] table.
* The Location Hierarchy is based on the Parent reference field in the Location \[cmn_location\] table.
* The Manager Hierarchy is based on the Manager reference field in the User \[sys_user\] table.
{#data-hierarchies__ul_xy1_5gp_ngc}
For example, the Location Hierarchy on the Location \[cmn_location\] table uses the Parent reference field. Each location has a parent, which is another record in the Location \[cmn_location\] table. For example, the Chicago and
Springfield location records have the Illinois location record's sys_id value in their parent field. Street addresses have sys_id locations for the cities they belong to in their parent field.
You can use the Location Hierarchy in the condition builder to create targeted queries. For example, you can specify a starting point in the Location Hierarchy and query down the hierarchy to retrieve all assets associated with
locations throughout that portion of the hierarchy.
## Hierarchical paths {#data-hierarchies__section_hzh_4jp_ngc}
Each record that belongs to a record hierarchy stores its hierarchical information in a path field. The path field is used for searches throughout the hierarchy in the condition builder.
Paths for each predefined record hierarchy are automatically generated by the ServiceNow AI Platform and stored in the path field on the Department \[cmn_department\], Location \[cmn_location\], and User \[sys_user\] tables.
* The path for departments is stored in the Parent HP1 field in the Department \[cmn_department\] table.
* The path for locations is stored in the Parent HP1 field in the Location \[cmn_location\] table.
* The management path is stored in the Manager HP1 field on the User \[sys_user\] table.
{#data-hierarchies__ul_cmk_vkp_ngc}
For example, the ServiceNow AI Platform automatically builds the hierarchy path for each location record in the Location \[cmn_location\] table. This creates a nested structure where each location can have sub-locations, forming a tree-like
hierarchy. The ServiceNow AI Platform also updates these paths when records are added, changed, or removed.
Many other tables contain self-referential fields, indicating a parent-child relationship between records. However, hierarchical paths aren't generated by the ServiceNow AI Platform in those tables until you define a hierarchy in the Record Hierarchy \[sys_record_hierarchy\] table.
## Use cases {#data-hierarchies__section_xcg_xxw_2dc}
The Department \[cmn_department\], Location \[cmn_location\], and User \[sys_user\] tables contain reference fields with parent-child relationships by default.
Department Hierarchy
: Search for assets associated with departments in your company using the Department Hierarchy record hierarchy.
Each department record contains a hierarchical path, allowing you to create queries in
the condition builder based on the department hierarchy. Since asset records have a Department reference field, you can query assets that belong to a specific department.
* Find all assets that belong to the IT department using a query like:\[Department\] \[is in hierarchy\] \[Department Hierarchy\] starting at \[IT\] which is \[Included\]
In this example, searching the
hierarchy returns assets associated with the IT department, including assets associated with departments that are part of the IT department, and so forth.
* Find all departments under the IT department by filtering directly on the Departments \[cmn_department\] table using a query like:\[Parent\] \[is in hierarchy\] \[Department Hierarchy\] starting at \[IT\] which is \[Included\]
{#data-hierarchies__ul_d4w_fpp_ldc}
Location Hierarchy
: Search for records according to location using the Location Hierarchy record hierarchy.
Each location record contains a hierarchical path, allowing you to create queries in the condition builder based on
the location hierarchy. Since incident records have a Location reference field, you can search for incidents based on a caller's location.
* Find all incidents from callers based in Illinois using a query like:\[Location\] \[is in hierarchy\] \[Location Hierarchy\] starting at \[Illinois\] which is \[Included\]
This query returns incidents
where the caller's location is Illinois, any city in Illinois, or a street address in any city in Illinois.
* Find incidents for cities and street addresses in Illinois, but not incidents where the caller location is simply Illinois using a query like:\[Location\] \[is in hierarchy\] \[Location Hierarchy\] starting at \[Illinois\] which is \[excluded\]
* Find all incidents based on your location as the logged-in user using a dynamic filter in a query like:\[Location\] \[is in hierarchy (dynamic)\] \[Location Hierarchy\] starting at \[My Location\] which is \[included\]
{#data-hierarchies__ul_y4m_51p_ldc}
Manager Hierarchy
: Search for records throughout the management chain in your organization using the Manager Hierarchy record hierarchy.
Each user record contains a hierarchical path, allowing you to create queries in the
condition builder based on the management hierarchy. Querying any table and selecting a reference field that points to the Users \[sys_user\] table enables you to search through the management chain.
* Find all incidents assigned to users who report to Bud Richman using a query like:\[Assigned to\] \[is in hierarchy\] \[Manager Hierarchy\] starting at \[Bud Richman\] which is \[Included\]
In this
example, searching the hierarchy returns incidents assigned to Bud Richman, including incidents assigned to users who report to Bud and their direct reports, and so forth.
* Find all incidents assigned to you and users in your own organization using a dynamic query like:\[Assigned to\] \[is in hierarchy (dynamic)\] \[Manager Hierarchy\] starting at \[Me\] which is \[included\]
* View the management chain itself by filtering directly on the Users \[sys_user\] table using a query like:\[Manager\] \[is in hierarchy\] \[Manager Hierarchy\] starting at \[Bud Richman\] which is \[included\]
* View the users who report to you by filtering directly on the Users \[sys_user\] table using a dynamic query like:\[Manager\] \[is in hierarchy (dynamic)\] \[Manager Hierarchy\] starting at \[Me\] which is \[included\]
{#data-hierarchies__ul_gbp_pdp_ldc}
## Overview of building a record hierarchy {#data-hierarchies__section_fk2_hww_jdc}
In addition to the predefined record hierarchies that are included with your instance, you can build a record hierarchy on a table of your choice.
Building a hierarchy between related records in the same table requires a self-referencing field. When building the hierarchy, you can either use an existing reference field that already defines parent-child relationships or create
a self-referencing field and populate it with the appropriate values for each record.
1. Identify a table that contains parent-child records that you want to use for building hierarchical queries. For example, to build queries based on related assets, you can define a record hierarchy based on the Asset \[alm_asset\] table.
2. Determine which reference field in the table defines the relationships between records. For example, the Parent field in the Asset \[alm_asset\] table describes the parent asset of an asset.
3. Create a hierarchy in the Record Hierarchies \[sys_record_hierarchy\] table and specify the table and reference field that you want to use. The ServiceNow AI Platform automatically adds hierarchical path information to each record in the table.
4. Create hierarchical queries in the condition builder by selecting the hierarchy that you created. Use operators to search through the hierarchy.
{#data-hierarchies__ol_cd4_wyv_2dc}
*[\>]: and then