1. Home
2. Blog
3. Why Zoho Automations Quietly Break When the Business Scales

Why Zoho Automations Quietly Break When the Business Scales

Published 28 October 2026 · Supraflow Engineering Team · 7 min read

A manufacturing client had Zoho CRM, Inventory and Books live together for almost a year. Everything worked: sales orders created invoices, invoices pushed stock out, stock levels synced across two warehouses. Then the business opened a third warehouse for a new product line, and the system quietly started lying about stock. A customer swore a warehouse was empty while Zoho showed stock available.

The actual bug

The original workflow rule had a warehouse ID hardcoded directly into the logic, in two places inside the rule itself and once more inside a Deluge function nobody had opened in eight months. The automation was never wrong for the two warehouses it was built for. It simply had no concept that a third one could exist.

This is not an automation bug in the sense of broken code. The code did exactly what it was told. It is a design gap: nobody mapped what should happen when the business changed shape, because at build time there were only two warehouses and writing the ID directly was faster than building a lookup.

Where hardcoded values hide in a Zoho implementation

• Deluge custom functions referencing a record ID, warehouse code, tax rate or price list directly instead of resolving it from a lookup or settings module.
• Workflow rule criteria comparing a field against a literal value (a specific user ID, a specific stage name) instead of a dynamic reference.
• Webhook payloads built with a fixed endpoint or branch ID baked into the URL or body.
• Blueprint transitions that assume a fixed set of approvers by user ID rather than by role or territory.

Why it is so easy to miss

Hardcoded values pass every test you run at launch, because at launch the assumption they encode (two warehouses, one tax regime, one approver) is still true. The failure only shows up once the business outgrows the original shape, often many months later, and by then nobody remembers which rule or function has the shortcut buried in it.

How to find them before they cause a problem

1. Search every Deluge function in the org for raw ID-looking strings and literal text comparisons rather than field or lookup references.
2. Read workflow rule criteria for any condition comparing against a specific name or ID instead of a category, role or status.
3. Ask, for every rule that references a specific entity: what happens the day there are two of these instead of one?
4. Push anything that currently has to be hardcoded into a dedicated settings or configuration module instead, so a future change means editing one record, not hunting through functions.

The fix, and what it actually cost

Rebuilding the warehouse logic around a proper lookup module instead of a hardcoded ID stopped the inventory sync errors, which had been quietly costing a handful of lost sales a week by the time anyone noticed. No new automation was added. The fix was removing something that should never have been built that way in the first place, which is often cheaper and safer than it sounds, because deleting a bad assumption carries less risk than adding a new rule on top of it.