Zoho Catalyst or Deluge: Where Code Should Run

Zoho Catalyst often comes up when CRM logic gets heavier. Deluge functions inside Zoho CRM are the natural place to start when a business needs custom logic: a calculation on save, a sync with another app, a scheduled clean-up job. As requirements grow, some of that logic starts to strain against function limits, becomes hard to test or needs libraries Deluge does not offer. At that point, teams look for somewhere else to run code. Zoho Catalyst is Zoho's own cloud platform for building and running applications and backend services, and it is one option. Other options include your own cloud services or an integration platform. This guide explains how to decide where code should run, comparing CRM functions with Zoho Catalyst and other hosting choices, so you move logic only when there is a clear reason.

What Deluge functions in Zoho CRM are good at

Deluge functions run inside Zoho CRM and are well suited to:

• Field calculations and updates triggered by workflow rules
• Simple integrations with other Zoho apps
• Small calls to external APIs
• Scheduled tasks that process modest numbers of records
• Button actions that help users complete a task

They need no separate hosting, use built-in CRM tasks and are familiar to many Zoho administrators. For a large share of business logic, they are the simplest choice.

Where CRM functions run into limits

Zoho CRM governs function execution with limits. The Zoho CRM developer documentation describes a credit-based system in which every function execution consumes one credit, each CRM edition has a daily credit allowance, and individual functions are also subject to execution time limits, response size caps and daily task quotas (Zoho CRM: Functions limits and quotas). Check the current figures for your edition on that page rather than relying on older numbers.

Signs that logic is outgrowing CRM functions include:

• Scripts that regularly time out or hit limits on busy days
• Long-running jobs that process large data sets
• A need for libraries, languages or tools that Deluge does not provide
• Complex logic that is hard to test inside the CRM editor
• Several systems depending on the same logic, not only the CRM

Our guide to Zoho Deluge timeouts covers ways to restructure scripts before deciding to move them.

What Zoho Catalyst offers

Zoho describes Catalyst as a full-stack cloud platform (Zoho Catalyst). Its product pages list services including Catalyst Functions, for backend logic in apps and microservices, Job Scheduling, for triggering jobs, and AppSail, described as a fully managed platform with custom runtime support. Because Catalyst is part of the Zoho ecosystem, teams already using Zoho may find it a familiar place to run heavier logic that supports their CRM.

Read the current Catalyst documentation and pricing for details on runtimes, limits and costs, as these change over time. If possible, build a small proof of concept for one job before committing, so you learn how deployment, logging and access control work in practice.

Other places code can run

Catalyst is not the only option. Depending on your team and systems, logic might also run on:

• Your own cloud services, such as serverless functions or containers on a major cloud provider
• An existing internal server or application that already handles integrations
• An integration platform that offers connectors and workflow tools

Each has different trade-offs in cost, skills, security reviews and maintenance.

Criteria for deciding where code runs

Weigh these factors for each piece of logic:

• Execution time and volume: can it finish within function limits on busy days?
• Language and libraries: does it need tools Deluge does not offer?
• Testing: can it be tested properly where it runs?
• Ownership: who will maintain it, and what skills do they have?
• Security: where will credentials live, and who can access the code?
• Cost: what will hosting, credits and maintenance cost over time?
• Dependencies: which systems call it, and which does it call?

There is rarely a single right answer. Many setups combine short CRM functions for record-level actions with an external service for heavy processing.

Worked example: placing logic by job

The table below is a hypothetical example of how one company might place different pieces of logic. It illustrates the reasoning, not a recommended design.

JobVolume and durationChosen locationReasonCalculate discount on deal saveSmall, instantDeluge functionSimple, record-level, needs CRM contextPush won deals to accounting systemModerate, one call per dealDeluge function with connectionFew calls, easy to monitorNightly reconciliation of thousands of invoicesLarge, long-runningCatalyst or other cloud serviceExceeds comfortable function limitsGenerate PDF reports with a specialist libraryModerate, library-dependentCatalyst or other cloud serviceNeeds tools Deluge lacksValidate address on form entrySmall, instant, in the browserClient-side scriptImmediate feedback to the user

Keep the CRM as the place users work

Wherever code runs, users should still see results in the CRM. When logic moves out, plan how results come back: updated fields, notes, status flags or related records. Make sure failures are visible in the CRM, not only in a remote log.

Plan the move carefully

When moving logic out of Deluge:

1. Document what the current function does, including edge cases
2. Build the new service and test it against the same cases
3. Run both in parallel where safe, comparing results
4. Switch the trigger to the new service
5. Keep the old function disabled but available for a short rollback period
6. Remove it once the new service is stable

Secure the connection between systems

External services need credentials to read and write CRM data. Use OAuth-based connections with the narrowest scopes possible, store secrets in a proper secrets store rather than code and log access. Review who can deploy changes to the external service.

Watch the total cost

Moving code can reduce function credit usage but adds hosting, monitoring and maintenance costs. Estimate the full cost before and after, including the time your team spends looking after another system.

Keep logic documented

As logic spreads across CRM functions and external services, documentation becomes essential. Keep a simple list of each job, where it runs, what triggers it and who owns it. Our guide to Zoho Deluge development covers organising functions so this list stays manageable.

Frequently Asked Questions

What is Zoho Catalyst?

Zoho describes Catalyst as a full-stack cloud platform with services such as Functions, Job Scheduling and AppSail for building and running applications and backend logic.

When should logic move out of Zoho CRM functions?

When it regularly hits function limits, needs tools Deluge lacks, is hard to test in the CRM or serves several systems, not only the CRM.

How are Zoho CRM functions limited?

The Zoho CRM documentation describes a credit system where each execution uses one credit, plus execution time limits, response size caps and daily task quotas.

Is Catalyst the only alternative to Deluge functions?

No. Logic can also run on other cloud services, internal servers or integration platforms, each with different costs and skills needed.

Decide where your CRM logic belongs

We review Deluge functions, identify logic that has outgrown them and plan moves to the right platform. See our Zoho CRM automation services, or talk to us about where your code should run.

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.