Zoho Sigma for Extensions, Widgets, and Connectors

Sigma is the platform Zoho gives developers for building extensions to its business apps. An extension can add widgets, buttons, custom fields, related lists, and connectors to apps like CRM, Desk, and Projects, and it installs and updates as a versioned package. It is the supported way to add a feature Zoho does not ship, instead of keeping a pile of loose scripts.

It is a monthly plan that covers the whole life of your extensions, not one build. We scope the requirement, set up the developer account and sandbox, build widgets, functions, and connectors, test against real roles and data, and package versioned releases. Then we install privately or clear Marketplace review, and update everything when Zoho changes an API. Monthly enhancement requests are part of the rate.

Marketplace is about extensions somebody else built: vetting them, installing them, setting permissions, and noticing when a publisher has abandoned one. Sigma is about extensions you build, from scoping through development, testing, packaging, and publishing. Many teams need both, because the honest answer to a request is sometimes an existing listing and sometimes code. We tell you which before we start.

No. Most extensions written for a single company are published privately, so they install only into your organization and never appear in a public listing. That keeps your process out of view and skips the Zoho review queue entirely. A public listing makes sense if you sell software, or if you are a partner deploying one extension across many client accounts.

Sigma supports the apps most teams run their business in, including CRM, Desk, Projects, Recruit, Books, Bigin, Inventory, and others. Each host app has its own widget locations, APIs, and review rules, so we build for the apps you use and test each one separately. A widget that behaves in CRM does not automatically behave in Desk.

Most first builds are live in four to six weeks. Scoping and environment setup take the first week or so, development and sandbox testing take the bulk of the time, and a private installation is quick once testing passes. Public Marketplace listings run longer because Zoho reviews them, and first submissions are commonly sent back over documentation, screenshots, or permission scopes.

Both, depending on where the logic belongs. Widgets are JavaScript against the Zoho SDK, because that is what renders inside the app. Server side logic is written as Deluge or serverless functions inside the extension package. We choose on maintainability rather than preference and document what went where.

The requests tend to fall into a few shapes: a widget that shows information from another system on a CRM record, a custom button that sends a record somewhere or starts a process, a connector that keeps Zoho and an outside tool in step, or a function that applies a rule the standard automation cannot express. We scope each one against what Zoho already does natively before agreeing to build it.

Yes, and it is a large share of what people ask for. We build connectors to the APIs your business depends on, use the narrowest OAuth scopes that work, map fields in both directions, and handle rate limits and retries. A slow or failing outside system then shows up as a clear message, not a frozen screen.

You do. The Sigma developer account is created under your organization, the extension is published under your name, and the source lives in a repository you control with builds we can reproduce. Nothing sits behind an agency login. If you bring the work in house or hire someone else, there is nothing to request and nothing to negotiate.

Every build runs in a sandbox or a separate test organization with representative data, using the roles your users hold rather than an administrator account with everything switched on. That is where permission errors, broken record saves, and slow API calls appear. We also test the wrong paths, since the failure people report is rarely the one you planned for.

Zoho retires API versions and changes SDK behavior on its own schedule, and an unmaintained extension eventually stops working without warning anyone who relies on it. We track the deprecation notices that touch your builds, update and retest the affected extensions in the sandbox, and release before the cutoff rather than after the support ticket.

Often you should not build an extension at all. Creator suits a standalone custom application, Flow suits moving data between systems on a trigger, and Catalyst suits a backend service. Sigma is right when the feature has to live inside an existing Zoho app, on the record your team already works from. We assess that first and tell you.

Yes, and we create it under your organization during onboarding. It owns your extensions and your publishing history, so it should never be ours. You get administrator access from day one, plus documentation on how a build is produced and where the source is kept.

Usually, as long as the source code exists somewhere. We read it, reproduce a build, and get it running in a sandbox, which is also where gaps show up between what it claims to do and what it does. You get a written assessment before committing to a monthly plan, including anything that needs rewriting rather than patching.

Small changes, such as adjusting a button, a field mapping, or a message, are enhancement requests that come out of your monthly plan. Because the package is versioned, a change is released as a new version with a changelog entry, so you can always see what moved and when. Larger additions are planned with you against your monthly hours.