Publishing to Zoho Marketplace turns internal tooling into a product, or a product into a distribution channel. It also turns a one-off build into something you maintain indefinitely. This is what the process actually involves.
Decide first whether you want a listing at all. A private extension installed only in your own org avoids review, avoids support obligations and avoids the maintenance commitment. Publish when distribution is the point — not because publishing sounds more finished.
Private vs public: the real difference
| Private extension | Marketplace listing | |
|---|---|---|
| Review process | None | Zoho security review |
| Who installs it | Your org only | Anyone |
| Support burden | Internal | External customers |
| Update cadence | When you like | Reviewed each time |
| Data handling scrutiny | Your own policy | Documented and assessed |
| Ongoing commitment | Until you stop | As long as anyone uses it |
What the review looks at
- Scope justification — why does the extension need each permission it requests?
- Data handling — what leaves Zoho, where it goes, how long it is retained.
- Credential storage — secrets must not be embedded in client-side code.
- External calls — every endpoint contacted, and why.
- Error behaviour — does it fail gracefully or leave records inconsistent?
- Listing accuracy — the description must match what the extension does.
Requesting broader permissions than you need is the most common cause of rejection, and it is entirely avoidable. Ask for exactly what the feature requires.
Getting to a submission
- Build against the extension framework — widgets, connectors and functions, in a developer org.
- Narrow the scopes to the minimum the functionality needs. Review this deliberately rather than accepting defaults.
- Write the data-handling description before submitting. If you cannot describe it clearly, the architecture needs revisiting.
- Test installation on a clean org — not the one you built in, which has state you have forgotten about.
- Test uninstallation. What is left behind, and is that acceptable?
- Prepare listing assets — description, screenshots, setup instructions.
- Submit and expect at least one round of questions.
Test on a clean org before submitting. The single most common surprise is an extension that works perfectly in the developer org and fails on install elsewhere, because it depends on a custom field or setting that was created manually months earlier and never made part of the package.
The costs people underestimate
| Item | Frequently overlooked because |
|---|---|
| Support channel | Free extensions still generate questions |
| Platform update compatibility | Zoho evolves; extensions break |
| Documentation upkeep | Setup instructions go stale |
| Review time on every update | Slows down urgent fixes |
| Multi-tenant edge cases | Other orgs are configured differently to yours |
| Reputation risk | A neglected listing with bad reviews is worse than none |
Multi-tenancy is the technical difficulty
An extension built for your org can assume your configuration. A published one cannot:
- Custom fields you rely on may not exist elsewhere — check and create, or fail clearly.
- Module names and layouts vary between orgs.
- Data volumes differ by orders of magnitude.
- Edition differences change what APIs are available.
- Regional data centres affect endpoints.
Handling this properly is most of the extra effort in going from private to published — typically more than the review itself.
Whether it is worth it
Publish when
- Distribution is genuinely the goal
- You will support it for years
- It solves a problem beyond your org
- You have a commercial model or lead strategy
Stay private when
- It encodes your specific process
- Nobody will own support
- You need to iterate fast
- Publishing is about prestige, not users
Considering a marketplace listing? Tell us what it does and who it is for — we will say honestly whether publishing serves you. See our Zoho extension service, Deluge guide, and the marketplace business case.