Zoho CRM Schedule Function for Large Record Volumes

Some CRM jobs should not wait for a user to click a button or for a record to be edited. Recalculating account health every night, flagging contracts that renew next month, closing stale leads, or syncing figures from another system all need to run on a timetable. The tool for this is a Zoho CRM schedule function: a Deluge function attached to a schedule that runs at a set time or frequency. Small schedules are easy. The difficulty starts when a job has to touch hundreds of thousands of records, because each function run has execution limits and every API call counts against your organisation's quota. This guide explains how we design Zoho CRM schedule functions that process large volumes reliably, with a worked example.

How a Zoho CRM schedule function works

Schedules are set up under the CRM's automation settings. Each schedule has a start time, a recurrence (such as daily, weekly or monthly) and a Deluge function to run. The function runs without a triggering record, so it has to find the records it needs itself, usually by searching, querying or paging through a module.

Typical uses include:

• Nightly recalculation of scores, ages or derived fields
• Daily checks for renewals, expiring documents or overdue tasks
• Periodic syncs from external systems that cannot push updates
• Housekeeping, such as archiving or flagging inactive records

Why large scheduled jobs fail

A schedule that works on a thousand test records can fail in production for predictable reasons:

• Execution limits. Each Deluge function run has limits on time and statements. A single run that tries to loop through a very large module will stop part way. Zoho's Deluge documentation describes how functions run and where to check the current limits.
• API credits. Integration tasks such as fetching and updating records consume credits from your organisation's daily allowance, described in Zoho's API limits page. A careless job can use credits other integrations need.
• No memory between runs. If a run stops part way, the next run starts from scratch unless you design it to resume.
• Silent failures. Without logging, nobody notices a job that stopped processing weeks ago.

Design principles for high-volume schedules

Make the work self-describing

The most reliable pattern is to select records by a condition that becomes false once a record is processed. For example: "accounts whose health score was last calculated before today". Each run takes the next slice of matching records, processes them and stamps them. If a run stops, the next one simply continues with whatever still matches. No cursor needs to be stored.

Process in bounded chunks

Each run processes a fixed number of pages and then stops, comfortably inside the execution limits. Running the schedule more often, or adding several schedules at staggered times, increases throughput without risking a timeout.

Update in bulk

Updating records one at a time multiplies API calls. Collect changes and send them in batches; Deluge's bulk update task accepts up to 100 records per call.

Keep a run log

Write a small record for each run to a custom module: start time, records processed, errors and whether work remains. This gives you a history and makes alerts easy.

Respect other integrations

Schedule heavy jobs outside business hours and cap how many records each run processes, so the job never consumes the credits your live integrations depend on.

Worked example: nightly account health scores

Suppose a business wants a health score on every account, recalculated daily from fields such as days since the last activity and number of open support cases. The illustrative function below processes accounts whose score was not yet calculated today, a few pages per run, and logs each run. Several schedules at staggered times overnight call the same function, and each run continues where the previous one stopped.

today = zoho.currentdate.toString("yyyy-MM-dd");
perPage = 200;
processed = 0;
errors = 0;

for each pageNo in {1,2,3,4,5}    // five pages per run
{
    // Always fetch page 1: processed records drop out of the criteria
    criteria = "((Health_Calculated_On:not_equal:" + today + ")or(Health_Calculated_On:equals:null))";
    accounts = zoho.crm.searchRecords("Accounts", criteria, 1, perPage);
    if(accounts.size() == 0)
    {
        break;
    }
    updates = list();
    for each acc in accounts
    {
        score = 100;
        days = ifnull(acc.get("Days_Since_Last_Activity"), 0).toLong();
        cases = ifnull(acc.get("Open_Cases"), 0).toLong();
        if(days > 60) { days = 60; }
        score = score - days - (cases * 5);
        if(score < 0) { score = 0; }
        upd = map();
        upd.put("id", acc.get("id"));
        upd.put("Health_Score", score);
        upd.put("Health_Calculated_On", today);
        updates.add(upd);
    }
    // Send in batches of up to 100
    batch = list();
    for each u in updates
    {
        batch.add(u);
        if(batch.size() == 100)
        {
            resp = zoho.crm.v8.bulkUpdate("Accounts", batch);
            batch = list();
        }
    }
    if(batch.size() > 0)
    {
        resp = zoho.crm.v8.bulkUpdate("Accounts", batch);
    }
    processed = processed + accounts.size();
}

log = map();
log.put("Name", "Health scores " + zoho.currenttime.toString("yyyy-MM-dd HH:mm"));
log.put("Records_Processed", processed);
log.put("Errors", errors);
zoho.crm.createRecord("Job_Runs", log);

Field names, the scoring rule and the criteria syntax are examples only; check search criteria against your field types and test in a sandbox. In a full version, each bulk update response is checked record by record and failures are counted in the log.

Estimating how long the job takes

InputHow to find itExample valueRecords to processCount matching recordsRRecords per runPages per run multiplied by page sizePRuns neededR divided by P, rounded upR / PWindow availableHours the schedule may runWRun frequency neededWindow divided by runs neededW / (R / P)Credits usedSearches plus bulk updates per run, multiplied by runsCompare with your daily allowance

Fill in your own numbers. If the runs needed do not fit the window, process fewer fields per record, run more often, or move the heavy calculation outside the CRM.

When a schedule function is not the right tool

Scheduled Deluge is ideal for moderate volumes and logic that lives naturally in the CRM. Consider other options when:

• The same field is being set to one value on many records; the mass update options in our guide to Zoho CRM mass update are more efficient
• Volumes run into millions or calculations are heavy; an external worker using bulk read and bulk write APIs is more economical
• The job must react within seconds; event-driven workflows fit better

For queries that need filters across several fields, COQL can return exactly the records required.

Testing before switching it on

Test the function in a sandbox with a realistic copy of the data. Run it manually first and check a sample of updated records by hand. Then attach it to a schedule in the sandbox and leave it for a few nights, checking the run log each morning. Confirm that a run interrupted part way is picked up correctly by the next one, and that workflows triggered by the updated fields behave as expected.

Monitoring and alerting

• Review the run log module daily, or build a dashboard from it
• Alert a named owner when a run records errors or when no run is logged in the expected window
• Track how many records still match the criteria at the end of the night; a growing backlog means the schedule needs more capacity
• Watch API credit usage, especially after adding or changing schedules

Credits are shared by every integration in your organisation, which is why our guide to Zoho CRM API limits is worth reading alongside this one.

Frequently Asked Questions

How do I create a Zoho CRM schedule function?

Write a standalone Deluge function, then create a schedule in the CRM's automation settings, choose the start time and recurrence, and attach the function.

Why does my scheduled function stop before finishing?

Most likely it reached an execution limit. Process a bounded number of records per run and design the job so the next run continues where the last one stopped.

How many records can a schedule process?

It depends on your edition's limits, available API credits, how much work each record needs and how often the schedule runs. Estimate it from records per run and runs per night.

Can a schedule run more than once a day?

Schedules support several recurrence options. For frequent processing, many teams create multiple schedules at staggered times attached to the same function.

Get your scheduled jobs running reliably

We design and build Zoho CRM schedule functions and external workers that process large volumes within your limits. See our Zoho CRM automation services, or talk to us about your scheduled jobs.

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.