Zoho CRM Mass Update: Limits and Faster Methods
Compare Mass Update, the Update Records API, Deluge bulkUpdate and Bulk Write, and see why big updates crawl and how a resumable batch worker finishes them.

Zoho CRM mass update limits compared: Mass Update API (50,000 per job), Update Records (100 per call) and Bulk Write, plus a resumable batch worker.
TL;DR: The Mass Update Records API sets one value on up to 50,000 records per scheduled job. Update Records or Deluge bulkUpdate changes up to 100 records per call. Bulk Write handles large CSV updates. Slow jobs usually update records one by one or fire workflows; a resumable batch worker fixes both.
Key takeaways
- Mass Update API: up to 50,000 records/job (one value).
- Update Records / bulkUpdate: 100 records/call (different values).
- Bulk Write for large CSV updates.
- Automation doesn't trigger above 1,000 records via Mass Update API.
- Email, lookup and multi-line fields can't be mass updated.
- Use a resumable, batched worker for big jobs.
Updating a field on a few hundred records in Zoho CRM is easy. Updating it on two hundred thousand records, without timeouts, without tripping API limits and without firing a flood of workflows, is a different problem. Teams often discover this when a nightly job that once took minutes starts taking hours, or stops halfway. This guide explains the Zoho CRM mass update options, their limits, and how we design decoupled batch workers that handle very large updates predictably, with a worked example in Python.
What is the Zoho CRM mass update limit?
Per Zoho's documentation, the Mass Update Records API can update up to 50,000 records per scheduled job, or 500 records per call when you pass record IDs. Update Records and Deluge bulkUpdate handle up to 100 records per call.
How do you bulk update records in Zoho CRM?
Zoho CRM gives you several ways to change many records. Each suits a different job.
MethodBest forKey limits from Zoho's documentationMass update from the list viewOne-off changes by an adminManual; limited to what the UI allowsMass Update Records API, scheduler typeSetting the same value on records in a custom viewUp to 50,000 records per job, run in the background; automation rules are not triggered above 1,000 recordsMass Update Records API, record IDsSetting the same value on a known list of recordsUp to 500 records per callUpdate Records API or Deluge bulkUpdateDifferent values per recordUp to 100 records per callBulk Write APILarge CSV-based updates or upsertsAsynchronous job; match records with a unique field via find_by
The Mass Update API also has field restrictions. Zoho's documentation notes that you can update only one field per call in most modules (three in Deals), and that fields such as email, lookup and multi-line fields cannot be mass updated. If your update needs different values per record, or touches those field types, use the Update Records API or Bulk Write instead.
Related reading: Zoho CRM Bulk Write API.
Why is my Zoho CRM mass update so slow?
When a mass update takes hours, the cause is usually one of these:
- A Deluge function loops over records one at a time, calling updateRecord for each
- The job fetches all records first, holds them in memory, and runs into execution limits
- Every update fires workflows, which call other functions and APIs in turn
- Calls are sent in parallel without respecting concurrency limits, so many fail with TOO_MANY_REQUESTS and are retried immediately
- There is no checkpoint, so a failure halfway through means starting again
Zoho's API limits documentation explains the two constraints that matter most: a credit allowance over a rolling 24-hour window, and concurrency limits per edition, with a separate sub-concurrency limit for heavier calls such as updates of more than ten records.
Related reading: Zoho CRM API limits.
What a decoupled batch worker looks like
A decoupled design separates three concerns that are often tangled together in one script:
- Selecting the work: find the IDs of records that need updating, using a query or a bulk read.
- Doing the work: a worker processes the IDs in batches of up to 100, with controlled concurrency and retries.
- Tracking the work: a checkpoint records which batches have succeeded, so the job can resume after any failure.
The worker runs outside Zoho, on a small server or scheduled container, so it is not bound by Deluge execution limits and can run for as long as the job needs.
Related reading: Deluge pagination with checkpoints.
Worked example: a Python batch worker for a Zoho CRM mass update
The illustrative worker below updates a large list of leads with values that differ per record. It sends batches of 100, keeps the number of parallel calls low, backs off when Zoho signals it is busy, skips workflows, and records each completed batch in a checkpoint file. Token refresh, logging and configuration are simplified.
import json, time, pathlib, requests
from concurrent.futures import ThreadPoolExecutor
API = "https://www.zohoapis.com/crm/v8" # use your data-centre domain
HEADERS = {"Authorization": "Zoho-oauthtoken YOUR_ACCESS_TOKEN"}
BATCH_SIZE = 100 # API maximum per call
MAX_PARALLEL = 3 # stay well under sub-concurrency limits
CHECKPOINT = pathlib.Path("mass_update_checkpoint.json")
def load_done():
return set(json.loads(CHECKPOINT.read_text())) if CHECKPOINT.exists() else set()
def save_done(done):
CHECKPOINT.write_text(json.dumps(sorted(done)))
def update_batch(batch_no, records):
body = {"data": records, "trigger": []} # skip workflows for bulk maintenance
for attempt in range(6):
r = requests.put(f"{API}/Leads", json=body, headers=HEADERS, timeout=60)
if r.status_code == 429 or "TOO_MANY_REQUESTS" in r.text:
time.sleep(min(pow(2, attempt) * 5, 120))
continue
r.raise_for_status()
failed = [d for d in r.json()["data"] if d["status"] != "success"]
return batch_no, failed
raise RuntimeError(f"Batch {batch_no} kept hitting limits")
def run(updates): # updates: list of {"id": ..., "Field": value}
done = load_done()
batches = [updates[i:i + BATCH_SIZE] for i in range(0, len(updates), BATCH_SIZE)]
todo = [(n, b) for n, b in enumerate(batches) if n not in done]
with ThreadPoolExecutor(max_workers=MAX_PARALLEL) as pool:
for batch_no, failed in pool.map(lambda nb: update_batch(*nb), todo):
if failed:
print(f"Batch {batch_no}: {len(failed)} records need review")
done.add(batch_no)
save_done(done)
Each call updates up to 100 records, which the API limits documentation counts at 1 credit per 10 records. That makes it easy to estimate the credits a job will use before you run it, and to schedule very large jobs across more than one day if needed.
Choosing the right approach for your job
- Same value on records in a view, under 50,000 records: use the Mass Update API's scheduler type and poll the job status.
- Different values per record, up to a few thousand: a Deluge scheduled function with bulkUpdate in batches of 100 is usually enough.
- Different values per record, tens or hundreds of thousands: use an external batch worker like the one above, or the Bulk Write API with a CSV file.
- Ongoing sync from another system: process only changed records, not the full table, and treat it as an integration rather than a mass update.
Do workflows run during a mass update?
With the Mass Update Records API, Zoho's documentation says automation rules are not triggered when more than 1,000 records are updated. Plan any dependent automation separately.
Handling workflows and automation during mass updates
Deciding whether workflows should fire is a business decision, not a technical detail. If a mass update reclassifies 50,000 leads, you probably do not want 50,000 assignment emails. Passing an empty trigger list skips workflows, approvals and blueprints for that call. If some automation must run, such as recalculating a score, run it deliberately as a separate step afterwards rather than relying on per-record triggers.
Why does a Deluge mass update stop halfway?
Usually it loops one record at a time and hits function time or execution limits. Batch the updates, run them from a schedule function or external worker, and checkpoint progress.
Monitoring a long-running job
A job that runs for hours needs visibility while it runs, not just a result at the end. We log the batch number, record count, credits used and failures for every batch, and send a summary when the job finishes or stops. A simple progress figure, such as batches completed out of total, lets the team see at a glance whether the job is on track. If the failure count in any batch rises above a threshold, the worker pauses and alerts someone rather than pushing on and creating a larger clean-up task.
Testing and rollback
Before running any large update in production:
- Export the affected fields for the records in scope, so you can restore them.
- Run the job on a small sample, then on a sandbox or test org with realistic volume.
- Estimate API credits from the record count and check them against your daily allowance.
- Schedule the run outside business hours, and tell the team what will change.
Two related guides go deeper into the limits and scheduling side: how to handle Zoho CRM API limits for high-volume updates and architecting custom schedulers in Zoho CRM to process very large record sets.
Frequently asked questions
What is the Zoho CRM mass update limit?
Per Zoho's documentation, the Mass Update Records API can update up to 50,000 records per scheduled job, or 500 records per call when you pass record IDs. Update Records and Deluge bulkUpdate handle up to 100 records per call.
How do I bulk update different values on many Zoho CRM records?
Use the Update Records API or Deluge bulkUpdate in batches of up to 100, or the Bulk Write API with a CSV and find_by on a unique field for very large sets.
Do workflows run during a mass update?
With the Mass Update Records API, Zoho's documentation says automation rules are not triggered when more than 1,000 records are updated. Plan any dependent automation separately.
Can we mass update lookup fields?
Not with the Mass Update API. Zoho notes that email, lookup and multi-line fields cannot be mass updated, so use Update Records or Bulk Write.
Why does our Deluge mass update stop halfway?
Usually it loops one record at a time and hits function time or execution limits. Batch the updates, run them from a schedule function or external worker, and checkpoint progress.
Speed up your large updates with us
We design Zoho CRM batch processing that runs within limits, resumes after failures and keeps automation under control. See our Zoho CRM automation services, or talk to us about your large data jobs.
Related reading: Zoho CRM automation.
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.
Need Help Implementing This in Your Business?
Our certified Zoho consultants and automation experts can help you design and deploy custom workflows tailored to your operations.
Book Free Consultation