Integration Flow Synchronization Logic Documentation

待补充

Third-Party -> CRM

Third-party data is first written to a temporary staging table. The staging table buffers large volumes of potentially duplicate records from third-party sources.

For each batch pulled from a third party, the system compares the incoming records against the staging table (comparison across all fields). Only records with detected changes will trigger the integration flow; records without changes will not trigger the flow.

About retries:

1. “Retry” on the intermediate table includes single-record retry and batch retry:
   • The system calls the “single query” API to re-query the third party and re-sync the data.
2. “Retry” on the staging table:
   • The system does not re-query the third party; instead, it re-triggers the integration flow using the data already in the staging table.
   • Use case 1: Data has not changed and does not require re-fetching from the third party, but you modified the integration flow and need to re-sync the data.
   • Use case 2: Data has not changed and does not require re-fetching from the third party, but some records previously failed to sync and need to be retried.

About whether the staging-table comparison runs when synchronizing historical data via tasks:

1. Time-range or custom-condition historical sync logic:
   • The system queries the third party for data. If some records already exist in the staging table, the system compares them to the staging data; changed records trigger the integration flow, unchanged records do not.
2. ID-based or CRM-scope historical sync logic:
   • The system queries the third party for data and does not perform staging-table comparison; all queried records will trigger the integration flow.

CRM -> Third Party

About retries:

All retries will re-query data from the CRM and re-trigger the integration flow.