Preserving table hierarchy in Instance Data Replication

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 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 Preserving table hierarchy in Instance Data Replication

    When configuring Instance Data Replication (IDR) in ServiceNow, it is important to decide how to handle parent-child table hierarchies. Before creating a replication set, determine if the table you want to replicate is part of such a hierarchy and choose whether to preserve it. You can replicate data either from the perspective of the parent table or the child tables, depending on your replication goals.

    Show full answer Show less

    Replication Strategies

    • Strategy 1: Preserve entire hierarchy and replicate child columns
      This approach preserves the full hierarchy, including all child table columns. You create an outbound entry for each child table, using a sysclassname filter to specify each child. For example, to replicate the Task table and all its children (Incident, Problem, Change Request), you define outbound entries for each table with corresponding filters. This ensures that records and their unique child columns are inserted into each respective child table on the consumer instance.
    • Strategy 2: Preserve hierarchy but replicate only parent columns
      Here, you replicate the parent table and include the sysclassname field in the included fields. This maintains the distinction between parent and child records on the consumer, but only the columns belonging to the parent table are replicated. Child records exist on the consumer, but without their unique child columns.
    • Strategy 3: Ignore hierarchy and replicate only parent table data
      This method replicates only parent table data by replicating the parent table and excluding the sysclassname field. This removes the distinction between parent and child records on the consumer, causing all replicated records to be treated as parent table records. No child table columns are replicated.

    Practical Implications for ServiceNow Customers

    Choosing the right strategy depends on your data replication needs:

    • If you require full fidelity of parent-child relationships and all child table data on the consumer instance, use Strategy 1.
    • If you want to preserve the record hierarchy without replicating child-specific columns, Strategy 2 is appropriate.
    • If your use case only needs parent-level data and you want to simplify replication, Strategy 3 is suitable.

    Understanding these strategies helps you configure replication sets effectively to meet reporting, auditing, or operational requirements while maintaining data integrity across instances.

    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:

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

    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:
    Table 2. Outbound entry
    Table Included Fields
    Task Class Name

    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:
    Table 3. Outbound entry
    Table Included Fields
    Task Any fields except for Class Name

    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.