Zoho Catalyst for the Zoho Developer
An overview to help Zoho developers take their first steps into Catalyst
This post is based on a presentation I gave for the Zoho Developer Community. Watch it here.
As a long-time Zoho developer, I’ve spent years working in Deluge—writing scripts, automating workflows, integrating APIs, and sometimes even pushing the platform to its limits. Deluge is powerful, but if you've ever bumped into its constraints or tried to build something a bit more complex, you’ve probably felt that itch for something more. That’s where Catalyst comes in.
Catalyst is Zoho’s full-stack serverless platform. And while it’s incredibly powerful, much of the content out there focuses on individual use cases. What’s missing is a bridge—a way for seasoned Zoho developers to comfortably step into Catalyst and see how familiar principles apply in this broader, more capable environment.
That’s the gap I want to help close.
Why Move from Deluge to Catalyst?
If you're like me, you probably started your Zoho development journey trying to solve every problem in Deluge. And for a long time, I saw that as a badge of honor. But I've shifted my mindset: I don’t have to live like Catalyst doesn’t exist.
Here’s the thing—Deluge is meant to extend the functionality of Zoho apps. It’s great for automating actions within CRM, Creator, Books, and so on. But it has limits. Catalyst lifts many of those limits while keeping you in the Zoho ecosystem.
Instead of struggling with long, complex Deluge functions, or awkward workarounds for limits like execution time or external libraries, you can just use Catalyst. And in doing so, you’re still operating in Zoho’s privacy-centric cloud, still close to your CRM data, still in the world your clients trust.
What’s the Same?
You’re already serverless.
That may sound odd, but it’s true—writing Deluge in CRM or Creator is a serverless act. You don’t manage infrastructure; you just write logic and it runs. That same mindset applies in Catalyst. You’ll find yourself more at home than you might expect.
Catalyst, like Deluge, is event-driven. You respond to triggers (like a field update) and execute a function. The difference? You now have full access to modern languages (Python, Node.js, Java), scalable architecture, and far better observability and testability.
What’s Better in Catalyst?
Here’s where things get exciting:
Scalability without limits: Execution limits like those in Deluge? Gone.
External libraries: Need a date recurrence engine? Pull in a Python package and get it done in five lines.
True parallel environments: Develop and test in dev, push to production when ready.
Observability: Logs that actually tell you what happened.
Cost: It’s pay-per-use and very cheap. Most of my production Catalyst setups cost under $10/month.
And then there’s complexity. You can build layered, asynchronous logic that would be nightmarish in Deluge but elegant in Catalyst.
Catalyst Architecture 101
Catalyst uses a microservice, event-driven architecture. This means:
Each function is single-purpose and disposable.
Functions communicate via events (like a record being edited or a value being cached).
The state of your app exists across various services—caching, file storage, databases—not necessarily in one place.
You should lean into the tools Catalyst gives you, rather than rebuilding everything in code.
Here’s the mindset shift: In Catalyst, the cloud is the application.
How to Trigger Things
You have a lot of options to start your logic in Catalyst:
API Gateway: Build APIs to call from CRM, Creator, or anything else. This is my go-to.
Event Listeners: Listen to changes in CRM or internal Catalyst events.
Job Scheduler: Schedule logic to run later or repeatedly.
Signals: Use template-based data transformation and external API interaction with minimal code.
Direct Function URLs: I recommend avoiding these—API Gateway gives you more control and security.
Writing and Organizing Code
You’ll write functions in Python, Node, or Java. I prefer Python—it’s fast, readable, and Catalyst supports it well.
There are two function types to know:
Basic functions: Ideal for most workflows.
Advanced functions: Use these if you need direct HTTP control (e.g., return a 404, redirect, etc.).
For orchestrating multiple steps, Catalyst offers Circuits. Think of these like flowcharts for your backend logic: wait, branch, retry, batch, and so on.
💡 Pro tip: If you're polling an API every 30 seconds, don’t write a loop in code. Use a Circuit with wait steps. Lean into the platform.
Managing State and Data
Serverless apps struggle with state, but Catalyst gives you tools:
Cache: For short-lived, small data. Lightning fast and great for coordination between functions.
Relational DB: Best for app settings or persistent metadata.
NoSQL DB: Fast, flexible, and surprisingly powerful once you get it.
File Storage: Great for holding large blobs of data temporarily (e.g., JSON results from another API).
Environment Variables: Per-function, so use them sparingly. I recommend encrypted storage in the DB for secrets instead.
Designing for Concurrency
Serverless is inherently concurrent. That’s a strength—but it’s also a challenge.
To avoid issues:
Design idempotent logic: Hitting an endpoint twice shouldn't break anything.
Pull fresh data right before final writes, if there's a time gap.
Use queuing structures like Job Scheduler or Event Listeners if things must run in order.
Conclusion
Zoho Catalyst isn’t just an alternative to Deluge—it’s the natural next step when your automation needs outgrow the scripting layer. And the good news? You already have the mindset to succeed.
If you’re a Zoho developer looking to level up your automation, embrace complexity, and build apps with modern tooling—all while staying inside Zoho’s ecosystem—Catalyst is worth learning.
Start with one thing. One script. One function. Then build from there.
Got questions or want to dig deeper? Reach out—I’d love to hear how you’re using Catalyst.