---
sourceDocument: Xanadu ServiceNow AI Platform Administration
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/xanadu/platform-administration

 Release :

    - xanadu

ft:locale :

    - en-US

ft:publication_title :

    - Xanadu ServiceNow AI Platform Administration

ft:clusterId :

    - platadm

bundleId :

    - platadm

workflow :

    - Platform


---

# View a table hierarchy and the extension model

# View a table hierarchy and the extension model {#ariaid-title1}

* Release version: Xanadu
* 
* Updated August 1, 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 minute to read

Determine the extension model used by a table.

## Before you begin

Role required: admin

## About this task

The extension model used by a table is not immediately apparent. While a hierarchy can use a single physical table, the platform displays tables as if each logical table has a unique physical table. For example, when specifying
a table for a workflow, you can select Change \[change_request\] or Incident \[incident\] even though the parent table, Task \[task\], uses a single physical table.

Administrators can view the status of flattened table hierarchies, but cannot flatten
additional hierarchies. You can [configure the
form](https://servicenow-prod.fluidtopics.net/1phGIP6~lfwMUKKczOxN0Q#configure-form-layout "Administrators or users with the personalize_form role can configure the form and related list layout.") to add the Extension model field if
necessary.

## Procedure

1. Navigate to AllSystem DefinitionTables.
2. Select a table record.
3. Review the Extension model field value, which indicates whether the table hierarchy uses multiple unique tables or a single flat table.
   * None: Indicates that the table uses the table per class model. Defines a unique physical table per logical table in a hierarchy. For example, there are separate physical tables for the Asset \[alm_asset\] table, and its child tables: Hardware \[alm_hardware\], Consumable \[alm_consumable\], Facility \[alm_facility\], and Software License \[alm_license\].  
     Note:  
     If a table has an empty Extension Model field, it is not necessarily a Table Per Class table. If the table extends another table, it actually inherits the model from any parent tables it is extending, and only when none of the parents have a defined extension model is the table's extension model Table Per Class. This can be seen on many tables that extend the Task table. Incident is a logical table that extends Task and is physically located on Task, but by default has a blank Extension Model value.

     When a table doesn't extend anything at
     all, and has a blank Extension Model field, it is a Table Per Class
     table.
   * Table per hierarchy: Defines a single physical table per logical table hierarchy. For example, there is a single Task \[task\] table on the MySQL database that contains all the Task, Incident, Problem and Change records. This single physical table is represented as separate logical tables.
   {#t_TableHierarchyAndTheExtModel__choices_jrb_rnh_1y}
{#t_TableHierarchyAndTheExtModel__steps_irb_rnh_1y}

*[\>]: and then