Deluge Scripting Examples That Actually Do Something Useful.

Most "Deluge examples" you find online are hello-world toys that fall apart the moment you point them at a real org. The snippets below aren't that. They're trimmed-down versions of patterns we write for clients every week — roll-ups, API calls, validation, scheduled jobs — with the error handling and gotchas that separate code that demos from code that survives production.

Deluge is Zoho's built-in scripting language — the thing that turns Zoho from a configurable product into a [programmable platform](/what-we-do/business-systems-integration/zoho). It runs inside custom functions, workflow rules, validation rules, buttons, and scheduled jobs, and it's how you make Zoho do what configuration alone can't. If you can read a little code, these examples will save you hours.

The difference between Deluge that demos and Deluge that survives production is almost never the language. It's the null checks, the return statements, and where you keep your credentials.

A caveat before the code: field and module API names below are illustrative — yours will differ — and every snippet should be tested in a sandbox first.

Where does Deluge run?

Before the examples, it helps to know the contexts Deluge executes in, because the same logic gets wired up differently depending on the trigger:

• Custom functions — called from workflows, blueprints, or buttons.

• Workflow rules — run on record create/edit/field-update.

• Validation rules — run before save, and can block it.

• Buttons & client scripts — run on demand from a record.

• Scheduled functions — run on a timer, with no user present.

• Zoho Creator — the same language, powering full custom apps.

Knowing the context matters: a validation function must return a status, while a scheduled function just acts. Get the context right and the rest is ordinary programming.

Example 1: Roll a child total up to the parent

A classic need — keep an Account's total deal value in sync as Deals change. Trigger this as a custom function on Deal create/edit:

// Roll all Deal Amounts up to the parent Account
account = deal.get("Account_Name");
if(account != null)
{
    accId = account.get("id");
    deals = zoho.crm.searchRecords("Deals", "(Account_Name:equals:" + accId + ")");
    total = 0.0;
    for each d in deals
    {
        if(d.get("Amount") != null)
        {
            total = total + d.get("Amount").toDecimal();
        }
    }
    upd = Map();
    upd.put("Total_Deal_Value", total);
    zoho.crm.updateRecord("Accounts", accId, upd);
}

The null checks aren't decoration — a single deal with a blank Amount will otherwise throw and stop the whole function.

Example 2: Call an external API

This is where Deluge shines. Here's a notification to a Slack webhook when a big deal is won — the same invokeurl pattern works for any REST API:

// Notify Slack when a high-value deal is won
if(deal.get("Stage") == "Closed Won" && deal.get("Amount") != null && deal.get("Amount").toDecimal() >= 50000)
{
    payload = Map();
    payload.put("text", "Deal won: " + deal.get("Deal_Name") + " ($" + deal.get("Amount") + ")");
    response = invokeurl
    [
        url: "https://hooks.slack.com/services/XXXX/YYYY/ZZZZ"
        type: POST
        parameters: payload.toString()
        headers: {"Content-Type":"application/json"}
    ];
    info response;
}

For authenticated APIs, don't paste tokens inline — store the auth as a Zoho Connection and add connection: "your_connection" to the invokeurl block. We go deep on why in our Deluge lessons learned the hard way, and on credential hygiene in security pitfalls of no-code platforms.

Example 3: Validate before save

Validation functions are different — they run before the record saves and can block it by returning an error map:

// Require a closing date on Closed Won deals
if(deal.get("Stage") == "Closed Won" && deal.get("Closing_Date") == null)
{
    return {"status":"error","message":"Closed Won deals must have a closing date."};
}
return {"status":"success"};

That returned map is the whole point — forget it and the validation silently passes. This is the kind of context detail that trips up people who only know configuration.

Example 4: A scheduled function

No user, no trigger record — just logic on a timer. Here's a nightly job that flags stale open leads:

// Scheduled function: flag leads untouched for 14+ days
leads = zoho.crm.searchRecords("Leads", "(Lead_Status:equals:Open)");
for each lead in leads
{
    daysIdle = (today - lead.get("Modified_Time").toDate()).toLong() / 86400000;
    if(daysIdle > 14)
    {
        upd = Map();
        upd.put("Needs_Follow_Up", true);
        zoho.crm.updateRecord("Leads", lead.get("id"), upd);
    }
}

For large datasets you'd page through results rather than loading everything at once — but the shape is this.

Common Deluge mistakes to avoid

The patterns above quietly handle the things beginners miss:

• No null checks — the number-one cause of "the function just stopped working."

• Hard-coded credentials — use Connections, never inline tokens.

• Ignoring API limits — bulk operations need batching and info logging.

• Forgetting the return in validations — the rule passes when you meant it to block.

Deluge sits in the low-code wave Gartner expects to drive 75% of new application development by 2026 (Gartner, via InfoWorld) — and Zoho, now past one million customers and 150 million users (Zoho / BusinessWire), is a big part of that. But low-code only stays low-effort when it's written with real discipline.

Book a free Zoho consultation if you've hit the edge of what you can script yourself — we write Deluge and custom Zoho builds for a living. Book a free Zoho consultation →

Write it like it has to last

Deluge turns Zoho into a real development platform: roll-ups, API integrations, validations, and scheduled jobs are all a few lines away. Mind the context (validations return, scheduled functions act), guard your null cases, store credentials as Connections, and test in a sandbox. When the logic outgrows what you want to maintain yourself, that's the line where custom development pays for itself — because the snippet that demos in five minutes and the one you trust to run unattended at 2 a.m. are rarely the same snippet.

Book a free Zoho consultation — bring the automation you can't quite get working and we'll show you the clean way to build it. Book a free Zoho consultation →

---

By the CodeStringers Team — Zoho Experts & Custom Software. CodeStringers is a custom software engineering firm with a dedicated Zoho practice, writing from work we've actually shipped for clients.

Find out what one connected Zoho system would change in the way you run.

In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.

Book the no-risk discovery

More on the same problem:

• Zoho Creator Scripting Guide: A Deluge Checklist for Workflows That Hold Up (article)

• 6 Custom Function Examples Every Zoho CRM Developer Should Know (article)

• Customer Success OS: A Guided Demo (video)

Frequently asked questions.

What is the difference between Deluge in Zoho CRM and Deluge in Zoho Creator?

The language is the same, but the built-in tasks differ by product. CRM functions use integration tasks such as record search and update against CRM modules, while Creator scripts use form and report tasks against Creator's own data and run in form events such as on load and on submit. A script written for one product needs its data calls rewritten for the other, even though the control flow and syntax carry over.

How do you run a Deluge function from a button on a record?

Create a custom button on the module, choose the function as its action, and map the record id as a parameter. The function runs when a user clicks and can return a message shown on screen. Buttons suit actions a person decides to trigger, such as generating a document or pushing an order to another system, and they give the user an immediate confirmation that the step ran.

Can a Deluge function be called from outside Zoho?

Yes. A function can be exposed as a REST API endpoint with its own key, so an external system or a webhook can call it with parameters and receive a response. That turns a few lines of Deluge into an integration surface without hosting anything. Treat the endpoint key as a credential, limit what the function can change, and validate every incoming parameter before using it.

How do you send an email from Deluge?

The sendmail task sends a message from a verified address to one or more recipients with a subject and body, and it can attach files held in a variable. Use it for internal notifications and digests; for customer-facing messages, prefer a workflow email alert with a reviewed template so wording and tracking stay consistent. Sending limits apply, so a scheduled job should group recipients rather than send per record.

How do you debug a Deluge script that stops without an error?

Add info statements with a label and the value at each step, run the function against the failing record, and read the log from the top. The usual causes are a null value used in arithmetic or string work, a lookup that returned nothing, or a validation function that never returned a status. Fix the first problem you find and re-run; later errors often disappear with it.