---
sourceDocument: Australia ServiceNow AI Platform Capabilities
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/servicenow-platform

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia ServiceNow AI Platform Capabilities

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Preserving table hierarchy

# Preserving table hierarchy in Instance Data Replication {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Preserving Table Hierarchy in Instance Data Replication

When utilizing Instance Data Replication (IDR), it's crucial to decide whether to replicate parent-child table hierarchies and the strategy for data replication.
Understanding the hierarchy helps determine if you want to preserve relationships and which columns to include in the replication process.
Show full answer Show less  

## Key Features

* **Strategy 1: Preserve the entire hierarchy and replicate child columns**
  * Creates outbound entries for each child table, including filters for sysclassname.
  * All columns from child tables are included in the replication.
* **Strategy 2: Preserve the hierarchy, but don't replicate child columns**
  * Replicates only the parent table while including the Class Name field.
  * Maintains distinction between parent and child records without replicating unique child columns.
* **Strategy 3: Ignore the hierarchy, and only replicate parent table data**
  * Replicates only the parent table and excludes the Class Name field.
  * All records on the consumer instance are treated as parent records, removing distinctions with child tables.

## Key Outcomes

By selecting an appropriate replication strategy, customers can effectively manage how data is structured and represented in the consumer instance, ensuring alignment with reporting and auditing needs based on their specific use cases. Understanding these strategies allows for informed decisions about data replication that can enhance data integrity and usability in ServiceNow environments.  
Decide if you want to replicate a parent-child table hierarchy and what strategy to use
for replicating the data in Instance Data Replication (IDR).

Before you create a replication set, determine if the table that you want to replicate is part
of a parent-child table hierarchy. If it is, decide if you want to preserve the hierarchy and
whether to replicate the data from the parent perspective (retaining only columns belonging to
the parent table) or from the child perspective (retaining all columns that belong to the child
tables). Review the following available strategies.

Strategy 1: Preserve the entire hierarchy and replicate child columns

:   You can preserve the entire hierarchy, including all of the child table columns, by creating an outbound entry for each child table, and specifying a sys_class_name filter for each child table.For example, to replicate the Task table and ensure that all of the columns from all
    of the child tables are included, specify the following:

    {#preserving-table-hierarchy__table_s3c_rr3_tvb__entry__2}

    | Table | Filter |
    |-|-|
    | Task | sys_class_name=task |
    | Incident | sys_class_name=incident |
    | Problem | sys_class_name=problem |
    | Change Request | sys_class_name=change |
    [Table 1. Outbound entries]

    {#preserving-table-hierarchy__table_s3c_rr3_tvb}

    And so forth, for all of the child tables, including filters with each table for the
    sys_class_name.

    With this strategy, records are inserted into each child table on the
    consumer, including data from the columns that belong to each child table on the
    producer.

Strategy 2: Preserve the hierarchy, but don't replicate child columns
:   To preserve the hierarchy but only replicate columns from the parent table, replicate the
    parent table and include the Class Name \[sys_class_name\] field in the Included Fields list. Including the Class Name field maintains the distinction between
    parent and child records on the consumer instance.  
    For example, if you want to replicate the Task table and its children (Incident, Problem, Change Request), but only replicate the columns that belong to the Task table, specify the following:{#preserving-table-hierarchy__table_bmj_5w3_tvb__entry__2}

    | Table | Included Fields |
    |-|-|
    | Task | Class Name |
    [Table 2. Outbound entry]

    {#preserving-table-hierarchy__table_bmj_5w3_tvb}

    In this strategy, the sys_class_name column on the consumer Task table receives
    entries for the parent table (task) and child tables (incident, problem, and change), and
    records are inserted into the respective child tables on the consumer. However, without the
    sys_class_name filter, the columns that are unique to each child table are not
    replicated.

Strategy 3: Ignore the hierarchy, and only replicate parent table data
:   To ignore the hierarchy and only replicate parent records, replicate the parent table and
    exclude the Class Name \[sys_class_name\] field from the Included Fields
    list. Excluding the Class Name field removes the distinction between parent and child records
    on the consumer instance. All replicated records on the consumer will be parent table
    records.  
    For example, if you want to replicate records from the Task table and simply consider all records as tasks for reporting or auditing purposes, specify the following:{#preserving-table-hierarchy__table_mt4_3x3_tvb__entry__2}

    | Table | Included Fields |
    |-|-|
    | Task | Any fields except for Class Name |
    [Table 3. Outbound entry]

    {#preserving-table-hierarchy__table_mt4_3x3_tvb}

    In this strategy, when you replicate the Task table, all replicated records
    have a value of task in the sys_class_name column, and no columns belonging to the child
    tables are replicated.