The opposite failure is just as common: a builder so determined to script everything that they rewrite in Deluge what a checkbox in the UI would have done in five seconds. Now that logic is invisible to the next person, untested, and one more thing to maintain. The real skill in Creator isn’t knowing Deluge — it’s knowing when to reach for it. Here’s how to make that call deliberately instead of by accident.

What each side is actually good at

Creator’s premise is that most business logic doesn’t need code. The visual builder handles a genuinely large surface area: field validations, conditional show/hide, lookups, formula fields, standard workflows triggered by form events, blueprints for state-driven processes, and reports with filtering, grouping and charts. When the platform can express your requirement natively, that’s almost always the right choice — not because scripting is hard, but because the no-code version is legible. The next person can open it, see what it does, and change it without reading a function.

Deluge exists for the things the builder can’t reach: multi-step logic, calling external systems, transforming data, orchestrating actions across forms, and any rule too conditional or dynamic to express by clicking. It’s a real scripting language, and it’s powerful. It’s also the part of your app that becomes technical debt if you’re not disciplined about it.

The question isn’t “can I script this?” You almost always can. It’s “is scripting this worth the maintenance it creates?”

Five signs you should stay no-code

Reach for the visual builder, not the script editor, when:

• The platform already has a native control for it. Field-level validation, mandatory rules, show/hide on condition, and simple calculated values all have built-in settings. Re-implementing these in Deluge hides logic that would otherwise be visible in the form config.
• The logic is simple and unlikely to change often. A one-off calculation or a straightforward workflow is clearer as configuration than as code.
• A non-technical teammate needs to maintain it. Creator’s whole value is that business owners can adjust their own apps. Every scripted rule chips away at that — it’s a door only the scripters can open.
• You’re tempted to script an on-load or on-user-input action. These run against the server every time they fire, and Creator counts them toward a throttle of roughly 120 action calls per minute per IP — the same bucket formula fields and lookup filters draw on. Heavy on-load logic shows up directly as a slow-loading form.
• The requirement is really a data-model problem. A lot of “I need a script for this” moments are actually “my forms and relationships are shaped wrong.” Fix the model and the need for the script often disappears entirely.

Five signs it’s time to write Deluge

Drop into code, deliberately, when:

• The builder genuinely can’t express it. Multi-step conditional logic, loops, string manipulation, or anything dynamic. This is what Deluge is for, and avoiding it here just produces convoluted workarounds that are harder to maintain than clean code.
• You’re integrating with another system. Calling an API, posting to a webhook, syncing with CRM or an external service. All script territory, and Deluge does it well.
• You need to process records in bulk or on a schedule. Nightly recalculations, batch updates, scheduled cleanups. The right mechanism matters here as much as the decision to script.
• The same logic repeats across the app. A reusable Deluge function written once and invoked from several places beats the same rule click-configured in five workflows that then drift out of sync.
• You’ve hit a hard wall in the UI. When a native feature’s limits stop you cold, a scripted approach — used carefully — is the honest answer.

The performance traps that decide it for you

Sometimes the choice isn’t about elegance. It’s about not breaking in production. Deluge has real limits, and they’re the reason “it worked in testing” turns into “it fails at scale.”

The big one: Deluge is metered by statements executed, not by time. A function has a ceiling in the range of roughly 5,000 to 50,000 executed statements depending on plan, and loops multiply against it. A for each loop whose body is eight statements exhausts a 5,000-statement budget at around 620 records. So a script that sails through your 100-record test quietly dies when the table grows. If you’re looping over records, you have to know how big that set can get.

A few more that shape the decision:

• There’s no set-based update in native Deluge. You can’t say “update all records where X.” You fetch and loop, which runs you straight back into the statement limit. Criteria-based bulk writes exist only on the API path, capped at 200 records per request.
• For large volumes, the answer is Batch Workflows, not a bigger loop. Zoho’s documented mechanism for processing thousands of records splits the work into asynchronous chunks specifically to overcome Deluge’s execution limits. If you’re reaching for a giant loop, you’re reaching for the wrong tool.
• There’s no “run in background” checkbox. Creator has no async keyword and no defer toggle. The only way to move heavy work off the user’s critical path is to flag a record and let a schedule or batch workflow pick it up later. Anything that must feel instant shouldn’t be doing heavy lifting in a synchronous form event.
• Filter on the right fields. Use mandatory or unique fields like ID or Email in criteria, and prefer && over ||, which the docs note is less efficient. Fetch all records only when you truly must.

A rule of thumb you can actually apply

When a requirement lands, walk it in this order:

1. Can the data model make this need disappear? Reshape first. You may not need logic at all.
2. Can a native builder feature do it? If yes, use it. The legibility is worth more than the cleverness.
3. If it needs code, how many records will it touch, and how often? Small and occasional: a clean function is fine. Large or frequent: design for batch workflows and schedules from the start.
4. Will this run on the user’s critical path? If it fires on load or on input, keep it minimal or move it off the path entirely.
5. Who maintains this in a year? If the answer is “only a scripter,” make sure that trade is worth it — and document what you wrote.