How to create parent child relationships in location hierarchy without creating custom tables

[Amol Pawar]

Hi Experts,

I have a requirement where I have to achieve parent child relationships without creating custom tables. We have a OOB hierarchy in our product like, Region > Campus > Site > Location. These tables are inter-connected with reference fields with each other.

Now our client wants to add some more levels in between like Sub-Region, Room, Door, Row, etc. There are around 10 more level they want to add, so without creating separate tables for each level, is there any other way we can create extra levels without affecting our OOB hierarchy?

Let me know if you have any ideas on it. Feel free to tag me if you need more information on it.

Thanks in advance,

Amol

[cerebrum001]

Hi Amol, what are the intended relationships between these location types? E.g. 1 Region  mapped to N Subregions. 1 Campus always linked to 1 Subregion or 1 Campus linked to both Subregion and Region. Depending on that (if most of the mappings are 1 to 1), you might want to consider extending the Location type choices (if needed). And for subregion, you might need to introduce a list collector variable, which you will only display if type is region. If there are multiple m2m relationships possible, please specify it.

[Mark_Branscombe]

The Location [cmn_location] table has a parent field out of the box that allows you to build hierarchies as per the attached screenshot.

[MuddanKT]

Use a Single “Extended Hierarchy” Table (CMDB-like pattern)

Instead of creating 10 additional tables, create one generic table (e.g., Hierarchy Node, Geo/Physical Level, or use existing cmn_location extended table). 
This table can represent all additional levels and store a parent-child relationship using the following fields:

Fields

• u_name – Name of the node (Room, Door, Row, etc.)

• u_type – Type of level (Choice: Sub-Region, Room, Door, Row…)

• u_parent (Reference → same table) – To build unlimited levels

• reference_to_oob (Reference → Region/Campus/Site/Location) – Optional binding

• Other metadata fields as required

• Advantages

  ✔ No need to create 10+ tables
  ✔ Supports unlimited hierarchy depth
  ✔ Works with recursive parent-child relationships
  ✔ Easy to report using:

  • Hierarchical lists

  • Tree views

  • Scripted GraphQL-like queries
    ✔ Fully compliant with platform standards (same pattern as CMDB CI hierarchy)

  This approach is recommended because ServiceNow already uses this recursive hierarchy pattern for:

  • CMDB (sys_class_name + parent-child relationships)

  • Knowledge categories

  • Portfolio/Program/Project

  • Cost centers

Alternative Option (Less Preferred): Reuse cmn_location With Custom Types

If the additional levels are still “locations,” you can extend the Location model by using:

• Location Type (choice field)

• Parent Location (OOB)

• Custom attributes

Why this works

cmn_location already supports recursive parent → child relationships, and you can represent 20+ hierarchy levels without new tables.

Limitations

• Mixing geospatial hierarchy with physical layout (rooms, rows, racks) may reduce clarity

• Harder for long-term maintenance if levels are semantically different