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

 Release :

    - zurich

ft:locale :

    - en-US

ft:publication_title :

    - Zurich ServiceNow AI Platform Capabilities

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Preparing for IDR

# Preparing for Instance Data Replication {#ariaid-title1}

* Release version: Zurich
* 
* Updated July 31, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 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 Preparing for Instance Data Replication

Instance Data Replication (IDR) enables ServiceNow customers to synchronize data between producer and consumer instances.
Proper preparation is crucial to ensure efficient, accurate replication and to avoid latency, performance issues, or data integrity problems.
Show full answer Show less  

## Preparing Your Instances

* **Geographic proximity:** Place producer and consumer instances in the same geographic region to reduce replication latency, though cross-region replication is possible.
* **Customer ownership:** Ensure instances belong to the same customer to streamline replication.

## Deciding Which Tables and Columns to Replicate

* **Avoid replicating system tables** (prefixed with `sys`) like `sysuser` to prevent insert/update failures and extra cleanup.
* **Avoid continuous replication of CMDB tables** due to performance risks; consider scheduled replication or filtered conditions if necessary.
* **Analyze table hierarchies:** Replicate all parent and child tables in a hierarchy to maintain data integrity and proper reference field population.
* **Analyze table relationships:** Include all referenced tables in replication sets to ensure reference fields are populated correctly on the consumer instance.
* **Column selection:** Replicate only necessary columns, excluding frequently system-updated or script-updated columns to reduce unnecessary replication and capacity consumption.

## Organizing Replication Sets

* Create individual replication sets per table for granular control, easier error isolation, parallel processing, and precise throughput tracking.
* Alternatively, group related tables into replication sets for simpler setup; however, issues affect all grouped tables and limit error isolation.
* If grouping, limit to five or fewer tables per set; larger numbers should be split into multiple sets.

## Preparing Target Tables on the Consumer Instance

* IDR uses the `sysid` field by default to synchronize records.
* Ensure target tables on consumer instances are empty or populated only via replication or cloning from the producer to avoid mismatches and duplicates.
* Avoid concurrent data imports or updates to target tables on the consumer during replication (e.g., LDAP imports) to prevent duplicate or unsynchronized records.
* If existing data cannot be cleared, either clean the target tables or use a custom Coalesce field to uniquely identify records instead of `sysid`.

## Reviewing Business Rules, ACLs, and Data Policies

* Verify that business rules on the consumer instance do not block the `idr.system` user from inserting, updating, or deleting records; failures are logged in the Replication Payload Error table.
* In bidirectional replication, updates triggered by business rules on the consumer instance do not replicate back to the producer.
* Ensure Access Control Lists (ACLs) allow the `idr.system` user appropriate permissions on target tables to avoid replication failures.
* Confirm data policies are compatible with replicated data; violations also appear in the Replication Payload Error table.

## Key Outcomes

By carefully planning and preparing your instances, tables, columns, and replication sets, and by reviewing business rules, ACLs, and data policies, you can ensure efficient, reliable, and consistent data replication across your ServiceNow instances. This preparation minimizes replication errors, maintains data integrity, and optimizes system performance.  
Before you set up Instance Data Replication (IDR), analyze the tables and columns in the producer and consumer
instances to replicate data successfully.

## Preparing your instances {#prepare-instance-data-replication__section_t3c_5f4_sdc}

Reduce latency by ensuring that the producer and consumer instances are in the same geographic region and belong to the same customer. You can replicate data between instances across different geographic regions. However,
replication latency can occur when instances are located in data centers in separate regions.

## Deciding which tables to replicate {#prepare-instance-data-replication__section_hjs_zdz_gtb}

Before you create a producer replication set, decide which tables to replicate. Avoid
replicating system tables (tables with a sys_ prefix). If you replicate system tables (like
sys_user, sys_user_group, or sys_user_grmember) that have existing data in the consumer
instance, insert and update failures can occur during replication. If you decide to replicate
these tables, you may have additional work afterwards to clean these tables.

Avoid continuous replication of CMDB tables. Replicating CMDB data as changes occur can create performance issues or unforeseen consequences with replication due to the number of records involved. If you must replicate CMDB tables, consider scheduling replication or use conditions to constrain the count of replicated records and ensure all required columns are included in the replication set.

For a list of tables to avoid replicating, see [Excluded tables in Instance Data Replication](https://www.servicenow.com/docs/Me1gOzwgDeWwuV1v7SU~_w "You can't replicate certain tables in Instance Data Replication (IDR). Child tables of tables in the exclusion list are also excluded.").

## Analyzing table hierarchies {#prepare-instance-data-replication__section_bbx_c2z_gtb}

For each table you want to replicate, determine if the table is a parent or child table. If the table belongs to a parent-child hierarchy, decide if you want to preserve the hierarchy and what strategy you want to use to move the hierarchy from the producer to the consumer.  
Important:  
To maintain data integrity and ensure that reference fields are populated on the consumer as you'd expect, you must replicate all of the parent and child tables in the table hierarchy.

See [Preserving table hierarchy in Instance Data Replication](https://www.servicenow.com/docs/o52dR_j31gI3hNPCf0GINQ "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).").

## Analyzing table relationships {#prepare-instance-data-replication__section_flk_2jx_4xb}

For each table you want to replicate, determine if the table has reference fields that point to other tables. If you are replicating a table with a reference field that points to another table, but you don't include that table
in your replication set, the reference field will be empty in the record on the consumer instance. Replicating table relationships maintains data integrity and ensures that reference fields are populated on the consumer as you'd
expect.

## Organizing replication sets {#prepare-instance-data-replication__section_itf_qq3_tvb}

As part of the planning phase, determine how you want to organize your replication sets and
the tables they contain.

* Create a single replication set for each table. This option requires more setup, configuration, and time management, but allows you to pause replication for a single table without impacting other tables.
  * Replication is performed in parallel using multiple jobs.
  * Throughput metrics are easier to track with separate replication sets.
  * When an error occurs, replication for a single table is affected instead of all multiple tables.
  {#prepare-instance-data-replication__ul_tv2_hms_y1c}
* Create a replication set for a group of related tables. This option is easier to set up and manage, but oversight and potential issues impact all tables in the group.
  * If you need find information about replication status, the logical name you use for this replication set might be easier to find and understand compared to using distinct replication sets for each table.
  * If you want to pause replication, you can do so for the entire group of tables by pausing replication from one replication set.
  * If a replication issue occurs on one table and replication stops, this stops replication for all tables in the replication set.

  {#prepare-instance-data-replication__ul_rpm_5q3_tvb}

  If you decide to group tables in a single replication set, try to limit it to five or fewer tables. If you have more than five tables to replicate, use multiple replication sets with five or fewer tables in each
  set.
{#prepare-instance-data-replication__ul_qpm_5q3_tvb}

## Deciding which columns to replicate {#prepare-instance-data-replication__section_n31_f1b_tvb}

For each table you want to replicate, decide which columns to include. Avoid including every
column in your replication set by default. Instead, decide which columns are necessary, and
exclude any sys_ columns or other columns that are updated by scripts automatically.

For example, if you include a column updated by the system automatically on a frequent basis,
IDR may replicate data more often than necessary. When the
system replicates this data, it can negatively impact the capacity subscription. Periodically
check the IDR License and Usage Details dashboard to monitor the message
count that is generated from the producer.

## Preparing target tables on the consumer instance {#prepare-instance-data-replication__section_zdm_f2z_gtb}

By default, IDR uses a record's sys_id field as the lookup
value to keep data synchronized between the producer and consumer instance. If the target table
contains existing data or records from prior data imports, the sys_id values in the consumer
don't match the sys_ids from the producer instance.

Always consider the producer instance as the source of truth. For optimal replication results,
follow these guidelines:

* Make the producer instance the exclusive data source for the consumer instance.
* Prior to replication, ensure that the target table in the consumer instance is empty. Ideally, the initial records in the target instance are created from data sent exclusively from the producer via a replication set or a clone.
* Ensure that there are no other ongoing data imports or updates to target tables on the consumer instance after replication starts.

{#prepare-instance-data-replication__ul_clf_rkz_gtb}

For example, if users from LDAP are imported to the consumer instance using a different data
source, the sys_ids for those records don't match the sys_id values in the producer instance. In
this scenario, existing user records in the target table on the consumer aren't updated and
duplicate records are created.

In situations where this cannot be avoided, clean the tables on the consumer instance prior to
replication. You must delete the records in the target table or ensure the sys_id values in
producer and consumer are the same.

Alternatively, you can use a custom Coalesce field to identify unique
records (instead of the default sys_id column) for replication. Use a custom
Coalesce column when records on the consumer instance have a different
sys_id for the same records on the producer instance. For more information on using a custom
Coalesce, see [Custom coalescing](https://www.servicenow.com/docs/_0MBwigenQ1TGUsBJ7KOdg#idr-coalesce "Coalesce records using a different column when records on the consumer instance have a different sys_id than the same record on the producer instance in Instance Data Replication (IDR).").

## Reviewing business rules {#prepare-instance-data-replication__section_ajn_n2z_gtb}

You can use business rules to trigger workflows after replication, such as sending a
notification or validating the replicated data. Review any business rules on the consumer
instance that might prevent the idr.system user from inserting, updating, or deleting records in
the target table.

If failures related to business rules occur, they appear in the Instance Data ReplicationReplication Payload Error table on the consumer instance. View the Error Message
field for details on the script that is causing the failure.

With bidirectional replication, records created on the producer instance are replicated to a consumer instance and vice versa. When the record is inserted on the consumer instance and it triggers a business rule that updates the record, that update is not replicated back to the producer instance.

## Reviewing ACLs {#prepare-instance-data-replication__section_clr_42z_gtb}

Review the ACLs in place on the target table in the consumer instance to ensure that IDR can replicate data successfully. Confirm that the idr.system
user has the appropriate roles for the target table.

If failures related to ACLs occur, they appear in the Instance Data ReplicationReplication Payload Error table on the consumer instance. View the Error Message
field for details on the ACL that is causing the failure.

## Reviewing data policies {#prepare-instance-data-replication__section_h3j_dfx_tvb}

Review any data policies in place on the target table in the consumer instance to ensure that
IDR can replicate data successfully. Confirm that the data
you are replicating satisfies the data policy.

If failures related to data policies occur, they appear in the Instance Data ReplicationReplication Payload Error table on the consumer instance. View the Error Message
field for details on the data policy that is causing the failure.

*[\>]: and then