What Zoho CRM widget development actually involves
Zoho CRM widget development means building small web applications that run inside your CRM screens rather than in a separate browser tab. Zoho describes widgets as embeddable UI components that you can create and add to your Zoho CRM, and you use them to perform functions that draw on data from third-party applications.
In practical terms, a widget lets your sales or service team see and act on information that does not live in the CRM record itself. Zoho's own example is a widget that displays a heatmap of the distribution of sales in a city. Other common uses are a custom dashboard, customised features such as SMS, and access to other services from within Zoho products.
The appeal for a business is simple: fewer systems for your staff to switch between, and processes that match how you actually work. The cost is also real. A widget is code, and code needs a build process, testing, hosting and someone who maintains it when your CRM or the connected system changes.
This guide explains what it takes to build a widget that keeps working after launch. It covers where widgets can appear, what your account needs, the toolchain, the limits Zoho sets, and how to test and ship without breaking your live CRM.
Where a widget can appear in Zoho CRM
Before you scope any widget, decide where your users will meet it. Zoho's developer documentation lists eight embedding locations: a dashboard, a web tab, a custom button, a custom related list, a wizard, a signal, the settings page and a blueprint.
Zoho's widget FAQ adds detail on how these behave. A widget can render when a user clicks a button, sit in a custom related list, or appear during blueprint transitions. It can also serve sales signals notifications, act as a wizard component, power telephony extensions, and run inside pop-ups or call-outs rendered through Client Script.
Why placement drives the design
Placement decides how much screen space you get, what context the widget receives and how often it loads. A widget on a record's related list sees one record at a time, while a web tab behaves more like a small standalone application. A blueprint widget becomes part of a controlled process, so a failure there can block a deal from moving forward.
A good rule is to match the placement to the moment of the task. If your team needs external data while viewing a customer, a related list or button is usually right. If they need a working area of their own, a web tab fits better. Agreeing this early prevents costly rework later.
When a widget is worth building, and when it is not
Many requests that arrive as "we need a widget" can be solved with standard configuration: fields, layouts, workflows and blueprints. A widget earns its cost when your team needs to run custom calculations, pull or sync data from another system, or work in an interface the standard screens cannot provide.
Typical candidates are integrations with accounting software, ERP or project tools, where your staff want to see external data next to the CRM record. An SAP Business One and Zoho CRM integration is a good example of that pattern, as is bringing an SMS service into Zoho CRM so messages are sent from the record.
A widget is the wrong choice when the requirement is really a missing field or a rule. It adds a build pipeline and a maintenance duty that configuration does not. If you are still deciding on the platform itself, a comparison such as Zoho CRM vs Salesforce helps you judge how much customisation each route will demand.
The table below sets out the trade-off in plain terms, so you can test a request against it before you commit budget.
| Standard configuration | Custom widget | |
|---|---|---|
| Who builds it | An administrator in Setup | A developer with JS, HTML and CSS skills |
| Data from other systems | Limited to what the CRM holds | Can use third-party application data |
| Where it appears | Standard CRM screens | Web tab, button, related list, dashboard and more |
| Edition needed | The edition you already run | Professional, Enterprise or Ultimate |
| Testing | Directly in the account or sandbox | Local run, then sandbox via External Hosting |
| Ongoing upkeep | Changes made in Setup | Code, validation and repackaging |
What your Zoho CRM account needs first
Widgets are not available on every plan. According to Zoho, they are available in the Professional, Enterprise and Ultimate editions of Zoho CRM. If you run a lower edition, factor an upgrade into the business case before any development starts.
The person who builds and manages widgets also needs the right access. You enable Developer Permissions for the profile that will work with widgets through Setup, then Users and Control, then Security Control, where you select the profile and switch the permission on. Keep that profile limited to the people who genuinely need it.
How many widgets you can have
Zoho allows a maximum of 200 widgets in Enterprise Edition and 200 in Ultimate Edition. Few businesses come close, but the cap is a useful reminder to treat widgets as a managed portfolio rather than one-off experiments.
Zoho's own training material lists the skills involved: basic knowledge of JS, HTML and CSS, APIs and SDKs, and the Zoho products concerned. If nobody on your team has those skills, plan for an external developer, and plan for who will own the code once the project ends. That ownership question matters more for long-term cost than the first build.
The toolchain: Zoho CLI from first command to ZIP file
Every widget project starts with the Zoho CLI. Zoho's Create Widget guide explains that once the CLI is installed, you run zet init to create a new project, and the command displays a list of services for creating a project template.
From there, a small set of commands covers the whole lifecycle:
zet runhosts the widget locally so you can test it.zet validatechecks whether the project adheres to Zoho's file and size limitations.zet packpacks the project for uploading to Zoho CRM and places the ZIP file in the project's /dist folder.
By default, the widget's HTML file sits in the app folder and is named widget.html. Everything the widget needs to render lives in that /app folder, which is why a clean folder structure is not a cosmetic concern.
For a business, the point is that a widget has a repeatable build. Ask whoever builds yours to keep the project in version control, to run validation before every release, and to document which ZIP file is live. Without that discipline, a small fix six months from now can turn into a reconstruction exercise.
Plain JavaScript or a framework such as React
Zoho states that widgets can be built using any client-side framework, including React JS. Its Kaizen series walks through building a Zoho CRM widget with ReactJS, and notes that the sample configuration is almost common to most frameworks.
The React setup has a few specific steps. You install react, react-dom and react-scripts with npm, and they are installed only for that project. A build script in package.json replaces the contents of the /app folder with the files from the /build folder. The property "homepage": "./" tells the system in production to look for static files within the same /app folder rather than in parallel directories.
The detail that trips up first builds
For a typical widget, the index page is named widget.html, but for ReactJS projects it must be named index.html. Small configuration points like this are exactly where widgets work on a developer's laptop and then fail after upload.
Choose a framework based on the complexity of the interface and on who will maintain it. React makes sense for a rich, stateful screen and a team that already knows it. For a simple panel that shows a few external values, plain JavaScript keeps the project smaller and easier to hand over.
How a widget talks to Zoho CRM
Widgets for Zoho CRM are built with Zoho's JS SDK. Zoho's FAQ explains that you add the SDK's CDN URL as a src within the head tag of your widget code. The API helpers in the SDK let the widget use the Zoho CRM APIs, and widgets also support ZRC, which gives API calls a unified syntax.
A widget starts with ZOHO.embeddedApp.init(), which initialises it and starts listening to events in the CRM. The most common event is PageLoad, triggered whenever an entity Detail page is loaded, and you use it to receive page data as parameters. ZOHO.CRM.CONFIG.getCurrentUser() returns user information such as name, ID, role and profile, which is useful when the widget should behave differently by role.
Working with Client Script and telephony
When a widget runs in a pop-up or call-out, it can exchange data with Client Script. Registering the Notify listener passes data from Client Script into the widget, and NotifyAndWait passes data from the widget back to Client Script. A button inside the widget can close it with ZOHO.CRM.UI.Popup.close().
If your organisation has no native telephony extension, the Dial and DialerActive listeners let you load a third-party telephony app inside a widget. DialerActive loads a contact's phone number onto the dial pad when a user clicks the telephone icon next to it.
Zoho's limits and why they shape the build
Zoho sets firm limits on widget projects. The maximum number of files in a project is 250, the maximum project size is 25MB, and each file is limited to 5MB. A lean plain JavaScript widget rarely approaches these, but a framework build with large libraries, images or fonts can.
This is why zet validate belongs in every release routine. It catches a project that breaches the limits before you try to upload it, rather than during a release window when your team is waiting. Keeping dependencies to what the widget actually uses also keeps load times reasonable for your users.
Publishing extensions to a wider audience raises the bar further, because the widget has to behave across accounts you do not control. Svennis has published five extensions on the Zoho Marketplace, every one rated 5 out of 5, and that experience is what shapes the release checks described in this guide.
The figures below summarise the size limits your developer should design around from the first commit, not discover at the end.
| Indicator | MB |
|---|---|
| Maximum project size | 25 |
| Maximum size per file | 5 |
| Source: help.zoho.com | |
Testing and hosting without touching your live data
Testing happens in two stages. zet run hosts the widget locally, but Zoho notes that a locally hosted widget can only be tested on the machine that hosts it. That is fine for a developer, but not for the people who will use it.
To test inside the CRM, you create a widget with External Hosting and enter the URL that zet run gives as the Base URL, in either a production or a sandbox account. For anything that writes data, use a sandbox. Testing a widget that updates records against your live customer base is a risk you do not need to take.
After testing, you package the widget and host it either internally or externally. Internal hosting keeps the files inside Zoho, while external hosting means you run and secure the server yourself, which adds an operational duty to the project.
Check the data flows
If the widget moves personal data between Zoho CRM and another system, review that flow against your GDPR obligations with whoever owns data protection in your business. Sector-specific setups, such as Zoho CRM for healthcare, deserve particular care here.
AI-assisted development: useful, with a review step
Zoho has introduced a zoho-crm skill intended to make its CRM developer tools, including APIs, functions, widgets, client scripts and queries, easier to work with in AI harnesses such as Claude Code, Codex, Cursor and VSCode. For widget work, this can speed up boilerplate, SDK calls and routine refactoring.
Speed does not remove the production checks. Generated code still needs to respect the file and size limits, the correct index page name, the /app folder structure and the right event listeners. It also needs a human review of how it handles data and permissions, because the widget runs with access to your CRM.
If you are weighing broader AI automation alongside CRM customisation, keep the two decisions separate. A widget solves an interface and integration problem inside Zoho CRM. AI automation addresses process work across systems, and it carries its own governance questions under the EU AI Act and GDPR.
A sensible approach is to let AI tools help your developer, while keeping the same release routine: version control, zet validate, sandbox testing and a named owner for each widget.
Practical next steps
Before you commission any widget, work through these steps in order. They keep the project small, testable and maintainable.
- Write down the task, not the solution. Describe what a user needs to see or do, and on which screen. Then check whether configuration alone can deliver it.
- Confirm your edition and access. Widgets need Professional, Enterprise or Ultimate, and a profile with Developer Permissions.
- Choose the placement. Pick from the eight locations Zoho supports, based on where the task happens.
- Agree the build routine. Version control,
zet validatebefore every release, and a record of which package is live. - Test in a sandbox. Use External Hosting with the
zet runURL before anything reaches production. - Name an owner. Someone must maintain the widget when Zoho CRM or the connected system changes.
If your CRM is still being set up or moved, settle that first. A clean migration to Zoho CRM and a solid Zoho CRM implementation give any widget a stable base, and that stability decides how long the widget keeps working.
