Writing Deluge with Zia in Zoho CRM: what this guide covers

This guide explains writing Deluge with Zia in Zoho CRM: what Deluge is, where a custom function fits, what help you can reasonably expect from Zia, and the review routine a draft needs before it runs on your live records. It is written for managers and owners who want to understand the work before they attempt it or pay someone else to do it.

This is part 1 of a three-part series on customising Zoho CRM with Zoho's own AI. This part covers customising the process: the automation that runs when something happens to a record. Part 2 turns to the record itself, meaning the fields, modules and layouts people see. Part 3 looks at what Zia's predictions and insights add once the structure is right.

If you are new to the product, the basics of Zoho CRM is the better starting point. Come back here once you know your way round modules, records and workflow rules.

One point runs through every section. An assistant can make a draft appear quickly, but a draft is still code that changes business data. The speed of drafting does not reduce the need to check, and the rest of this post is about how to check well.

What Deluge is and where a custom function belongs

Deluge stands for Data Enriched Language for the Universal Grid Environment. Zoho's Deluge help describes it as an online scripting language integrated with Zoho services. It is Zoho's own language, built by Zoho, and over forty Zoho products currently support it.

A scripting language is a form of programming language used to write short scripts that run inside a main program and direct how it behaves. In Zoho CRM that main program is your CRM account. When an action happens, such as a lead being created, it can trigger a Deluge script that carries out a workflow action.

Where the function sits

A custom function is a named Deluge script stored in Zoho CRM. On its own it does nothing. You attach it to a workflow rule, and the rule decides when it runs. The rule holds the trigger and the conditions; the function holds the logic that the standard workflow actions cannot express.

Deluge can also make API calls to external services, not only to Zoho products. That is powerful, and it is also the part that needs the most care, because data then leaves your CRM. Deluge brings queries into the language itself, so fetching and updating records takes few lines. Few lines can still change many records.

What Zia can and cannot be relied on for

Zia is the AI built into Zoho CRM. Zoho's Zia page says it can create modules, reports and workflows in seconds, retrieve data you ask for, turn images into Canvas views, "and more". It can also identify repetitive activities and suggest workflows, macros and owner assignment automation. For a fuller view of the everyday features, see what Zia actually does for a small sales team.

Zoho's page does not set out in detail what Zia's help with writing or explaining code covers, so this guide makes no promise about it. What changes in practice is who can attempt a function. A sales manager who could never write Deluge from a blank editor can now get a plausible draft and ask what each line does.

Two different things called Zia

Do not confuse Zia helping you write code with Zia tasks inside Deluge. The Deluge task list includes Artificial Intelligence tasks under Zia, such as Analyse Sentiment, Translate, Recognize Text and Detect Face. Those are functions your script calls. They are covered in the same review as any other task.

The routine below works whatever produced the draft: Zia, another assistant or a colleague. It treats every draft as unproven until it has been read, tested and measured against the limits.

Who is allowed to do what: permissions and editions

Before anyone drafts anything, check who holds which permission. Zoho CRM separates the rights involved, and the separation is useful. It lets you give someone the ability to write functions without also letting them change what triggers them in production.

Permission	What it allows
Manage Extensibility	Create custom functions
Manage Automation	Create and update workflow rules
Manage Sandbox	Manage the sandbox
Modules Customization	Add custom fields

The permission for custom functions and the permission for workflow rules are separate. A draft function is harmless until a workflow rule calls it, so the person who attaches it to a live rule should be the person who signs off the review.

Check your edition

Zoho's worked solutions state the edition they need. The meeting example used later in this guide is marked as available in Zoho CRM Enterprise edition and above, and it uses workflow rules, Deluge script and the sandbox. If your organisation is on a lower edition, confirm what is available before you plan around it. Our Zoho CRM page explains how we approach implementations for UK firms.

Worked example: a Friday meeting for every new lead

Zoho publishes a solution that makes a good first function, because the result is easy to see. Zoho's meeting solution uses a custom function and a workflow rule to schedule a one-hour meeting for the upcoming Friday whenever a new lead is created. Zoho rates it low complexity with an implementation time of 15 minutes.

What the function does

The meeting runs from 9:00 AM to 10:00 AM on the upcoming Friday.
It is titled with the lead's name followed by a custom suffix, such as "Review Lead".
It is assigned to the lead owner and associated with the lead record.

How to set it up

Write or paste the function in the sandbox, not production.
Go to Setup > Workflow Rules and click + Create Rule, choosing the Leads module and the create trigger.
Attach the custom function as the rule's action.
Create test leads and check each meeting's date, time, title, owner and link.

Two details in Zoho's own notes show why reading matters. The sample code uses a +05:30 time zone offset, and Zoho says to replace it with your own value. And in the day numbering the code uses, Sunday is 1 and Monday is 2, so an off-by-one mistake lands the meeting on the wrong day. A draft from any source can carry either error while looking perfectly tidy.

The review routine, line by line

Reading comes before running. At Svennis we have the draft read by someone other than its author before it runs anywhere, because an author, human or AI, tends to read what was meant rather than what was written. The checklist below is the routine, in the order we would apply it.

Check	What to look for	Why it matters
Module and field names	API names match your account, not a sample's	Zoho's code works for other modules only after you change the module name and parameters
Hard-coded values	Time zone offsets, record IDs, day numbers, suffixes	Sample values such as +05:30 must be replaced
Inputs	Every argument is passed and has the expected type	A wrong type can produce an "invalid data" error
Loops	Any integration task inside a for each	Each run of the task consumes an external call
Connections and scopes	The connection name exists and holds the right scope	Integration tasks fail without the scope they require
External calls	Where data is sent and what is sent	Deluge can call any applicable external service
Response handling	The script checks what came back before it continues	Failures still count and still return a response

A real case from the Zoho community forum shows the input check at work. A user fetched related deals with zoho.crm.getRelatedRecords("Deals", "Accounts", input.accId.toLong()) and updated them with zoho.crm.updateRelatedRecord. The code threw an error saying the data was invalid, even in a simplified test with a single deal ID and account ID. Syntax that looks correct is not proof that the call is being used correctly.

Testing in the sandbox before anything touches live data

A sandbox is a separate copy of your CRM setup where you can build and test without affecting production records. Both of the Zoho solutions cited in this guide give the same instruction: test the workflow rule in a sandbox before deploying it to your production environment. Access is controlled by the Manage Sandbox permission.

What to test

The normal case. A complete lead created by a typical user.
The awkward cases. Missing names, empty owners, records created by import or by another integration.
The boundary dates. For the meeting example, a lead created on a Friday, a Saturday and the day before a clock change.
The volume case. Several records at once, to see how often the function runs.

Use Deluge's info statement to print what the script receives and returns while you test; the forum user above used it to show the error response. Remove or reduce the output before deployment.

Write down what you tested and what you saw. When the function is moved to production, the same person should create one real test record there and check it by hand. If something is wrong, deactivate the workflow rule first; the function stops running as soon as nothing calls it.

The limits that apply: external calls and loops

Deluge integration tasks call other services through an API, and those calls are counted. Zoho's help pages for the Zoho Show integration tasks, the Zoho Notebook tasks and the Zoho One getUserGroups task all say the same thing. Each execution triggers a back-end API request, and that request is deducted from the External Calls limit of the service running the script, based on your pricing.

The counting rule is the one drafts most often get wrong. Only executions that receive a response count, whether success or failure. What counts is how many times the task actually runs, not how many times it appears in the script. Zoho's example is plain: a task inside a for each loop that iterates five times consumes five external calls, even though it appears once.

What to check in a draft

Move integration calls out of loops where one call can fetch everything needed.
Respect paging limits. The getUserGroups task, for example, accepts between 1 and 200 records per page.
Check required scopes. That same task needs the ZohoOne.Groups.READ scope and a connection name.

Multiply the calls per run by the number of records the rule will fire on in a busy week. That figure, not the script's length, tells you whether a function is safe.

When a custom function is the wrong answer

The easiest function to review is the one you do not write. Zoho's own solution for formatting serial numbers in Contacts uses a workflow rule and a Deluge function to turn a serial number such as 123456789012345 into the pattern 123 456 789 012345. Zoho rates it medium complexity, with an implementation time of 30 minutes.

The same page offers a simpler route: a validation rule that only accepts serial numbers entered in the specified pattern. The page does note that a field with a tooltip and validation rule on its own is not entirely foolproof. The choice depends on whether you want to correct the data after entry or refuse bad data at the door.

A rule of thumb

If a standard workflow action, validation rule or field setting does the job, use it.
If Zia's suggested workflows or macros cover the need, start there.
Reach for a custom function when the logic needs calculation, related records or another service.

The general principles of when to configure rather than build are covered in how to customise your CRM. Every function you add is something that must be understood and maintained by whoever inherits your system.

For serial numbers, a validation rule refuses bad entries while a function corrects them afterwards. Workflow rule with Deluge function / Validation rule. What it does: Rewrites the number into the 123 456 789 012345 pattern / Accepts only numbers en

What this means for a UK company

Most of the review routine is the same anywhere, but three points deserve attention in a UK organisation. The first is time. Zoho's sample carries a +05:30 offset that Zoho tells you to replace. A single fixed offset cannot follow British Summer Time, so any function that schedules meetings or calculates deadlines should be tested on both sides of a clock change.

The second is personal data. Deluge can send data to external services, and Zia's data enrichment gathers details about leads and customers from the internet and from email signatures. Before a function passes customer data to another system, record what goes where and why, in line with your UK GDPR obligations.

The third is governance. Many UK firms have small teams where one person holds every admin right. Split the Manage Extensibility and Manage Automation permissions where you can, so drafting and deploying are separate steps. If you are also considering AI automation beyond Zoho's built-in features, the same separation of drafting from sign-off applies there.

Practical next steps

You can start this week without writing a line in production. Work through the steps in order and stop at any point where the answer is unclear.

List the candidates. Write down two or three repetitive tasks your team does by hand in Zoho CRM. Check whether a standard workflow action or validation rule would handle each one.
Check permissions and edition. Confirm who holds Manage Extensibility, Manage Automation and Manage Sandbox, and whether your edition supports the features involved.
Build the Friday meeting example in the sandbox. Replace the time zone offset, check the day numbering and test the awkward cases.
Run the checklist. Use the table in this guide on any draft, whatever produced it, and have someone other than the author read it.
Count the calls. Estimate external calls for a busy week before you deploy.

Once the basics feel familiar, the intermediate Zoho CRM guide covers the wider set of features that functions often connect to.

Sources

Looking for a Zoho partner in the UK? Svennis has been a Zoho Premium Partner since 2011, with more than 200 implementations delivered. See how we work as a UK Zoho Partner.

Writing Deluge with Zia in Zoho CRM and what to check before you deploy