Zoho Creator lets people close to a process build the application for it, which is both the benefit and the risk. Governance means deciding in advance who may build, what counts as production rather than a personal tool, which masters an app may write to, and who inherits it when its author changes role.
Every organisation that adopts a low-code platform reaches the same milestone: the day someone in operations builds something genuinely useful that nobody in IT has heard of. How the business responds to that day decides whether it ends up with a capability or a liability.
How it goes wrong, which is rarely dramatic
The failure looks like this. A coordinator builds an app to track a process. It works. Two teams start relying on it. The coordinator changes role. Nobody knows how the calculation works, the data sits outside the main estate, and a report shown to management has quietly been wrong for two months.
No individual acted badly. The organisation simply never decided who owned what.
Four decisions, best made before the second app
Who is allowed to build
Not everyone, and not only IT. Nominate a small group — usually two to five people who already understand the processes — and give them a short induction. Everyone else raises a request. This one rule prevents most sprawl.
What counts as production
Draw the line at dependency, as in the diagram above. An app two people rely on, or that feeds a report shown upward, follows the rules: named owner, documented purpose, tested changes.
Where the data lives
Decide which masters an app may read and which it may write to. Customer and item masters generally belong to the core products, with the app referencing them. An app holding its own copy of the customer list has created a reconciliation problem that will outlive it.
Who inherits it
Every production app needs a named owner and a deputy, recorded somewhere findable. When the owner moves on, transferring the app is part of the handover — exactly like a client relationship.
A register that takes ten minutes a month
| Field | Why it matters |
|---|---|
| App name and purpose | Prevents two teams building the same thing |
| Owner and deputy | Answers “who do I ask?” without a hunt |
| Users and criticality | Tells you what to test before a platform change |
| Data it reads or writes | Shows the blast radius of a mistake |
| Last reviewed | Surfaces the apps nobody has looked at in a year |
A shared sheet is enough to begin with. The discipline matters more than the tooling.
Guardrails that slow nobody down
- A place to build that is not production. Nobody should be developing against live data because it was the only option available.
- A naming convention. Dull, and it saves hours the first time anyone audits anything.
- Role-based permissions as a default. Set when the app is built, not after someone sees a record they should not have.
- A quarterly review. Thirty minutes to ask of each app: still used, still owned, still correct? Retire what fails.
Frequently asked questions
Does governance remove the speed advantage?
Only if it is made approval-heavy. The four decisions above take a day to settle and add no friction to routine building — they define which builds need a second pair of eyes.
What about apps that already exist without owners?
Run one amnesty. Ask teams to register what they use, promise no blame, then triage: adopt, rebuild or retire. The list is almost always longer than management expects.
How much documentation is enough?
Enough that a competent colleague can pick the app up in an afternoon: purpose, data sources, key logic, known limitations. One page per app is usually sufficient.
When should a build move to engineering?
When it involves complex financial calculations, several external integrations, high transaction volumes, or anything a regulator may inspect. Recognising that ceiling early is a governance decision, not a failure.
Where to start
Open a sheet and list every custom app your business currently depends on, with an owner beside each. If any line is blank, you have found your first governance task — and it costs far less to fix now than after that person leaves.
References
Topic inspiration: the Developer Platforms section of the Zoho Blog. This article is Kelevo Software’s own analysis and wording, written from our implementation experience; no text has been reproduced from Zoho’s publications.
Kelevo Editorial
Written by the Kelevo consulting team — Zoho Premium Partner in India, delivering CRM, finance, HR and custom application implementations end to end.
More Blogs
Zoho Flow, Deluge and APIs: Which Integration Tool to Reach For
Native links, then Zoho Flow, then Deluge functions, then the REST API. Try them in that order — and answer the four…
Zoho Creator or a Standard Module: Where the Line Actually Sits
Build when making the standard module fit would misrepresent what the business does. Configure when it merely needs adjusting — plus the…
Zoho CRM and Zoho Books: How the Integration Actually Works
Customers, items, quotes and payment status move between the two products; pipeline, tax and the ledger do not. A field-by-field look at…
Want this applied to your own Zoho estate?
A 45-minute discovery call with a Zoho architect maps your processes to the right products and gives you an indicative scope.