Zurich: sys_record_hierarchy table usageIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } ProblemThe customer can report that in the Record Hierarchy (sys_record_hierarchy) Table, there are 4 active records present in Zurich Instance which were not present in Yokohama. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Zurich Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Root Cause1. The discrepancy in the Record Hierarchy Table is due to OOB records created with the upgrade to Zurich, as the plugin com.glide.hierrarchical_record_support is available in Zurich but was disabled in Yokohama due to performance issues (PRB1840224). Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } The sys_record_hierarchy table in ServiceNow is a system table introduced in the Zurich release, used to explicitly define and manage hierarchical relationships for records within a single table. It helps formalize multi-level hierarchies, making it easier to manage and query related records with unlimited depth.Functionality:=========This feature is designed for tables that are "self-referencing," meaning they have a field that refers back to a record in the same table.Examples include the cmn_location (Location) or sys_user (User) tables, where a location can have a parent location, or a user can have a manager who is also a user.When a record hierarchy is created in the sys_record_hierarchy table:A new Hierarchy Path field is automatically created on the targeted self-referencing table. This field stores the complete path of the record within the hierarchy.This path is used by the platform to power hierarchical queries and native UI components.It is different from a standard table extension hierarchy, where one table extends another. The sys_record_hierarchy table is specifically for managing a record-level parent-child structure within a single table.Practical benefits:=============Improved query performance: The pre-computed path in the Hierarchy Path field enables highly efficient querying of an entire hierarchy.Native IN_HIERARCHY operator: Developers can now use the IN_HIERARCHY operator in both UI and GlideRecord queries to easily find all records belonging to a particular parent or its descendants.Centralized definition: It provides a standard, supported way to define and manage hierarchical relationships that were previously difficult to implement.Example: User hierarchy==================To illustrate, consider the sys_user table. A user can have a manager, who is also a record in the sys_user table. Before the sys_record_hierarchy table, querying for all employees under a specific manager would have required a custom script to recursively traverse the hierarchy.With the sys_record_hierarchy configured for the sys_user table:A hierarchy_path field is automatically maintained, for example, top_manager_sys_id/middle_manager_sys_id/employee_sys_id.A single query, such as manager IN_HIERARCHY top_manager_sys_id, can now retrieve all subordinate users efficiently, without writing complex scripts.Please check for the detailed use case in the below product docs:https://www.servicenow.com/docs/bundle/zurich-platform-administration/page/administer/table-administration/concept/data-hierarchies.htmlhttps://www.servicenow.com/docs/bundle/zurich-platform-administration/page/administer/table-administration/task/create-record-hierarchy.html