Exploring Instance Data Replication

  • Release version: Australia
  • Updated March 12, 2026
  • 4 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 Exploring Instance Data Replication

    Instance Data Replication (IDR) facilitates the replication of data updates from a producer instance to one or more consumer instances, ensuring consistent data across different environments. This capability is essential for organizations wanting to synchronize data within or between companies.

    Show full answer Show less

    Key Features

    • Continuous Replication: Automatically replicates updates in near-real time from the producer to consumer instances.
    • Scheduled Replication: Allows for historical data replication at predefined intervals.
    • Bidirectional Replication: Enables updates to be reflected on both producer and consumer instances.
    • Discrete Replication: Ensures each consumer instance receives updates independently.
    • Transformation Capabilities: Maps data to differently named tables/columns in consumer instances and modifies data before replication using adapters.
    • Post-Replication Workflows: Triggers workflows such as notifications or validations after data replication.

    Key Outcomes

    IDR helps maintain data integrity across instances, minimizing delays in data availability. However, it is not suitable for cloning instances or replicating certain metadata and system tables. Users should monitor performance, especially with large attachments or CMDB data, to avoid potential issues. Testing IDR in a pre-production environment is recommended to mitigate risks related to data loss and exposure.

    For further configuration and usage guidance, users can explore additional resources related to IDR administration and references.

    Instance Data Replication (IDR) replicates data updates on one instance, called the producer instance, to one or more other instances, called the consumer instances.

    IDR overview

    Maintain consistent data across different instances using IDR.

    • Automatically replicate data to one or more other instances.
    • Synchronize data between different organizations in your company or even between different companies with separate instances.
    • Data that is in transit during a crash is recoverable.

    IDR users

    Table 1. Users
    User Description
    IDR admin The IDR admin determines which tables and columns to replicate and analyzes table hierarchies and relationships. The IDR admin creates producer and consumer replication sets and monitors ongoing replication.

    IDR workflow

    This image shows how IDR replicates data from multiple tables on a producer instance to multiple consumer instances.

    Figure 1. Replication overview
    Data replicates from a producer instance to one or more consumer instances.
    1. On the producer instance, the IDR admin specifies the tables and table columns to replicate by creating a producer replication set.
    2. The IDR admin activates the producer replication set, which makes the producer data available for replication to consumers.
    3. The IDR admin creates consumer replication sets on one or more consumer instances to receive the producer replication set data.
    4. On each consumer instance, the IDR admin requests approval from the producer instance.
    5. On the producer instance, the IDR admin approves or denies the requests from each consumer instance.
    6. On each approved consumer instance, the IDR admin activates the consumer replication set. After the consumer replication is activated, data that is updated in a producer replication set automatically updates the corresponding data in the consumer replication sets.
    7. On each consumer instance, the IDR admin can optionally replicate existing data from the producer instance by seeding data to the consumer instances.
    8. On either the producer or consumer instance, the IDR admin can optionally replicate data to tables or table columns that have different names on the consumer instance by configuring a transformation in the replication set.
    9. On either the producer or consumer instance, the IDR admin can optionally modify producer data before replicating it to a consumer by configuring an adapter in the replication set.

    IDR benefits

    Table 2. benefits
    Benefit Feature Users
    Continuously replicate inserts and updates from a producer instance to one or more consumer instances in near-real time, ensuring minimal delay. Continuous replication Administrator
    Schedule replication of historical inserts and updates from a producer instance to one or more consumer instances at predefined intervals. Scheduled replication Administrator
    Continuously replicate inserts and updates from a producer instance to a consumer instance in near-real time, with changes on either side replicated back to the other. Bidirectional replication Administrator
    Continuously replicate inserts and updates from a producer instance to specific, distinguished consumer instances in near-real time, ensuring each consumer instance receives updates independently. Discrete replication Administrator
    Map producer data to tables and table columns that are named differently on consumer instances. For example, you can modify and map table columns to localize data for different locales. Transform replication data Administrator
    Modify producer data before replicating it to a consumer instance using an adapter. For example, you can configure adapters that perform string and mathematical operations, such as converting one currency to another, or converting one time zone to another. Transform replication data Administrator
    Trigger post-replication workflows such as generating notifications or validating replication using business rules. Triggering workflows after replication Administrator

    IDR limitations and when not to use IDR

    • Do not use IDR to clone instances.

      IDR does not replicate metadata tables, child metadata tables, and most user and system tables. IDR is designed to replicate data, not to clone instances. For example, the Application File [sys_metadata] table and tables that extend [sys_metadata] (including the Business Rules [sys_script], Catalog [sc_catalog], and Workflow [wf_workflow] tables) are excluded and can't be replicated. For details on cloning, see Instance Clone.

    • Avoid using IDR to replicate a series of large attachments on a regular basis. If you need to include attachments that are larger than 10 MB regularly, monitor IDR to ensure that the lag time doesn't exceed expectations.
    • 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.
    • You cannot replicate Edge Encrypted, Field Encryption, and Password (2-Way Encrypted) fields.
    • IDR does not synchronize data archiving between instances. For example, archiving records or restoring archive records on a producer instance doesn't affect archived records on the consumer instance (and vice versa). You must create and manage archive rules for each instance independently.
    • Additional replication limitations:
      • Maximum record size is 10 MB.
      • Continuous replication supports up to approximately 1 million records per day.
      • Seeding must not take longer than seven days to complete.
      • You can only create one scheduled replication set, with only one outbound entry in that set.
    Warning:
    IDR overwrites data on instances and can replicate sensitive data. Avoid potential data loss and data exposure, by testing your IDR implementation in a pre-production environment. See data privacy in IDR for more information.

    What to explore next