Scheduled Data Sync for Zoho CRM Done Right

Many businesses run two systems that must agree: product prices live in the ERP, customers live in the CRM, and order statuses live in an operations tool. Real-time integrations are not always possible or necessary. The source system may have no webhooks, the data may only matter a few times a day, or the volume may be too high to push record by record. A scheduled data sync solves this by moving only what has changed, at fixed intervals, with clear rules for conflicts and failures. This guide explains how to design one for Zoho CRM, how to choose an interval, how to track what has changed safely and how to recover from missed runs, with a worked example.

When a scheduled data sync is the right choice

Real-time and scheduled syncs both have a place. A short comparison helps decide:

FactorReal-time (webhooks, notifications)Scheduled syncFreshnessSecondsMinutes to hoursSource requirementsMust send eventsOnly needs a way to list changesBehaviour during outagesEvents can be lost without a queueNext run catches upLoad on systemsSpread across the dayConcentrated in runsDebuggingMany small eventsDiscrete runs with clear logs

A scheduled sync suits reference data such as products, price lists and territories, nightly financial updates such as invoice status and outstanding balances, and any source that cannot send events. It also makes a good safety net behind a real-time feed, catching anything the live integration missed.

The parts of a reliable scheduled data sync

Every dependable scheduled sync has the same components:

• A watermark: the timestamp or ID of the last change processed, stored durably
• A change query: a request to the source for records changed since the watermark
• An overlap window: a few minutes of deliberate overlap, so changes written during the previous run are not missed
• Idempotent writes: upserts keyed on a stable external ID, so processing a record twice does no harm
• Conflict rules: which system owns each field when both have changed
• Run logs: records read, created, updated, skipped and failed, for every run

Of these, idempotent writes matter most. With an overlap window, some records will be processed twice. If the write is an upsert matched on an external ID, the second pass simply updates the same record. Zoho's Upsert Records API checks duplicate check fields, including user-defined unique fields, and updates the matching record or inserts a new one, handling up to 100 records per call.

Choosing the interval

Pick the longest interval the business can accept, not the shortest one possible. Ask how quickly a change must appear in the target and what happens if it is late. Price lists that change weekly can sync nightly. Stock levels that affect quotes may need hourly runs. Anything that needs updates within seconds probably belongs in a real-time integration instead.

Zoho CRM schedule functions can run for up to 15 minutes per execution, according to Zoho's Functions limits and quotas, and each execution consumes function credits. HTTP calls made with invokeurl time out if the other system does not respond within 40 seconds. Both limits influence how much one run can do and how often it should run.

Worked example: hourly product price sync from an ERP

Suppose an ERP holds 8,000 products and their prices. On a typical day, 50 to 300 products change, usually in the afternoon. Sales reps quote from Zoho CRM, so prices there must be no more than an hour out of date. The ERP offers an API that lists products updated after a given time, and the CRM Products module has a unique custom field, ERP_Product_ID.

The schedule function below runs hourly. It reads the watermark, asks the ERP for changes since then, upserts them into Zoho CRM in chunks of 100 and saves the newest timestamp it saw. It is illustrative and untested; the ERP endpoint, field names and connection names are placeholders.

cp = zoho.crm.v8.getRecordById("Sync_Checkpoints", checkpointId);
since = cp.get("Products_Watermark");
// subtract a five-minute overlap from since here before calling the ERP
erp = invokeurl
[
    url: "https://erp.example.com/api/products?updated_after=" + encodeUrl(since)
    type: GET
    connection: "erp_conn"
];
changes = ifnull(erp.get("items"), List());
chunk = List();
newest = since;
for each item in changes
{
    rec = Map();
    rec.put("ERP_Product_ID", item.get("id"));
    rec.put("Product_Name", item.get("name"));
    rec.put("Unit_Price", item.get("price"));
    chunk.add(rec);
    if(item.get("updated_at") > newest)
    {
        newest = item.get("updated_at");
    }
    if(chunk.size() == 100)
    {
        body = Map();
        body.put("data", chunk);
        body.put("duplicate_check_fields", {"ERP_Product_ID"});
        resp = invokeapi
        [
            service: zohocrm
            path: "/crm/v8/Products/upsert"
            type: POST
            body: body.toString()
            headers: {"content-type": "application/json"}
        ];
        chunk = List();
    }
}
// send any remaining records in chunk the same way, check each response for errors,
// then save newest to the checkpoint record and log the run totals

The overlap window is applied when the watermark is used: each run asks for changes from five minutes before the saved value, and the upsert makes the repeated records harmless. A typical afternoon looks like this:

Run (IST)Watermark usedChanges returnedUpsertedErrorsNew watermark14:0012:55120120013:5815:0013:532102091 (invalid price)14:5916:0014:549595015:57

The failed record from the 15:00 run is logged with its ERP ID and error, and a person fixes the price in the ERP; the next run picks it up because its updated time changes. Comparing timestamps as text works here only because the ERP returns them in a fixed ISO format; if your source does not, convert them before comparing.

Handling conflicts and deletions

Decide ownership field by field. In the example, the ERP owns product names and prices, so the sync always overwrites them, while descriptions written by marketing in the CRM are never touched. If both systems can edit the same field, pick a rule, such as the most recent change wins, and log every overwrite so disputes can be traced.

Deletions need separate handling because a deleted record no longer appears in a "changed since" query. Common options are a soft-delete flag in the source that the sync reads, a periodic full comparison of IDs between systems, or marking CRM records inactive rather than deleting them.

Recovering from missed runs

Because the watermark only moves forward after a successful run, a missed or failed run is caught up automatically by the next one, which simply asks for a longer window. Alert when the watermark has not moved for more than two intervals, as that means runs are failing repeatedly. Keep a manual way to reset the watermark to an earlier time, so you can replay a period after fixing a mapping error.

For syncs that process large volumes in each run, our guide to the Zoho CRM schedule function covers batching and checkpoints in more depth. For financial data, our guide to Zoho CRM ERP integration explains how reconciliation catches differences a sync can miss.

Frequently Asked Questions

What is a scheduled data sync?

A process that runs at fixed intervals, fetches records changed since the last run and applies those changes to another system, using a stored watermark to track progress.

How often should a scheduled sync run?

As infrequently as the business can accept. Nightly suits reference data, hourly suits prices or stock, and changes that must appear within seconds belong in a real-time integration.

How do we avoid missing changes between runs?

Use a watermark that only advances after a successful run, overlap each window by a few minutes and make writes idempotent with upserts on an external ID.

How are deleted records handled?

Through a soft-delete flag in the source, a periodic comparison of IDs between systems, or by marking records inactive instead of deleting them.

Set up reliable syncs with us

We design scheduled syncs between Zoho CRM and other systems with watermarks, upserts, conflict rules and run logs. See our Zoho CRM automation services, or talk to us about your data sync.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.