Zoho CRMのウィジェットは8種類ある|設置場所ごとの違いと使い分け

Zoho CRMのウィジェットは、HTML・CSS・JavaScriptで作った独自のUIをCRMの画面内に埋め込める機能です。標準機能やDeluge関数だけでは実現できない画面を作りたいときの、最後の手段になります。
ただ「ウィジェット」とひとくくりに呼ばれることが多い一方で、実際にはどこに設置するかによって8種類に分かれており、渡ってくるデータも使えるSDKのAPIも変わります。ここを理解せずに作り始めると、後から「このタイプではレコードIDが取れない」と気づいて作り直すことになりがちです。
この記事では、8種類それぞれの特徴と向いている用途、そして共通の作成手順や制限をまとめます。
ウィジェットとは何か
ウィジェットは、Zoho CRM内に埋め込めるUIコンポーネントです。JS SDK(Embedded App SDK)を通じてCRMのデータにアクセスできるため、外部サービスのデータをCRM画面に表示したり、CRM内のデータを独自のUIで操作したりできます。
公式の位置づけとしては「外部サービスとシームレスに連携するためのインターフェースコンポーネント」ですが、実際には外部連携がなくても、標準UIでは表現できない画面(ガントチャート、カレンダー、独自の集計ビューなど)を作るために使われるケースも多い機能です。
なお、ウィジェットの利用はエンタープライズプランとアルティメットプランのみです。スタンダード・プロフェッショナルでは使えないため、要件定義の段階でプランを確認しておく必要があります。
8種類のウィジェットタイプ
現在のZoho CRMがサポートしているウィジェットは、次の8種類です。
| # | タイプ | 設置場所 | 主な用途 |
|---|---|---|---|
| 1 | Home page dashboard | ホーム画面のダッシュボード | KPI表示、独自の集計ビュー |
| 2 | Web tab | Webタブ(タブバー) | 独立した画面、管理ツール、一覧アプリ |
| 3 | Custom button | カスタムボタン | レコードに対する処理、入力ダイアログ |
| 4 | Related list | カスタム関連リスト | レコード詳細画面への情報追加 |
| 5 | Wizard | ウィザードのステップ | 段階的な入力フォームの一部 |
| 6 | Signal | シグナルの通知詳細パネル | 通知に紐づく詳細情報の表示 |
| 7 | Settings | 設定画面 | 拡張機能の設定UI |
| 8 | Blueprint | ブループリントの遷移 | 遷移時の入力・確認UI |
以下、それぞれを詳しく見ていきます。
1. ダッシュボードウィジェット
ホーム画面のダッシュボードに埋め込むタイプです。ダッシュボードは本来、レポートをグラフとして可視化するための機能ですが、ウィジェットを追加することで標準のグラフでは表現できない形式のビューを載せられます。
標準のダッシュボードコンポーネント(Comparator、Funnel、象限分析、Target Meterなど)で足りない可視化が必要になったときの選択肢になります。ガントチャート、ヒートマップ、カスタムのタイムラインなどが典型例です。
特定のレコードに紐づかない画面なので、レコードIDは渡ってきません。表示するデータはウィジェット側でAPIを叩いて取得する設計になります。
2. Webタブウィジェット
タブバーに独立したタブとして表示されるタイプです。組織内の全ユーザーが表示でき、画面全体を使えるため、8種類のなかでもっとも自由度が高いタイプといえます。
社内向けの管理ツール、独自の一覧・検索画面、複数タブを横断するダッシュボードなど、「1画面のアプリ」を作りたいときに向いています。DelugeからWebタブを呼び出すこともできます。
Webタブウィジェットでは、ブラウザの戻る操作に対応した HistoryPopState イベントが用意されている点も、画面内で状態遷移を持たせる設計の助けになります。
3. カスタムボタンウィジェット
カスタムボタンのアクションとして、ウィジェットをポップアップ表示するタイプです。ボタンは詳細画面・一覧画面など複数の位置に設置できます。
「一覧で複数レコードを選択して、まとめて何か処理する」「詳細画面から専用の入力ダイアログを開く」といった用途に向いています。関数だけでは入力UIを出せないため、ユーザーに何かを選ばせたり入力させたりする処理は、ボタンウィジェットの出番です。
このタイプが特徴的なのは、PageLoad イベントで受け取れるデータの形です。関連リストウィジェットが単一のレコードIDを受け取るのに対し、ボタンウィジェットでは選択された複数レコードのIDが配列で渡り、さらにボタンの設置位置(ButtonPosition)も含まれます。一覧画面と詳細画面で同じウィジェットを共用する場合は、この値で分岐させる設計になります。
4. カスタム関連リストウィジェット
レコード詳細画面の関連リスト枠に埋め込むタイプです。8種類のなかでもっともよく使われるタイプではないでしょうか。
外部サービスのデータをレコードに紐づけて表示する(Google Driveのファイル一覧、外部システムの取引履歴など)のが本来の用途ですが、CRM内のデータを独自レイアウトで見せる用途にも使われます。標準の関連リストでは表形式しか選べないため、進捗バーやチャートで見せたい場合はこのタイプになります。
PageLoad イベントで、対象のタブ名(Entity)とレコードID(EntityId)が渡ってくるため、コンテキストを前提とした実装ができます。
5. ウィザードウィジェット
ウィザードは、長い入力フォームを複数の画面に分割する機能です。そのステップの1つとして、ウィジェットをコンポーネントとして埋め込めます。
標準のウィザードでは扱えない入力方式(外部APIを叩いた候補選択、地図からの位置指定、複雑な条件分岐UIなど)が必要なステップだけをウィジェット化する、という部分的な使い方ができるのが利点です。
JS SDKには ZOHO.CRM.WIZARD.Post が用意されており、ウィジェット側で入力した値をウィザード本体に渡せます。
6. シグナルウィジェット
シグナル(SalesSignals)は、見込み客や連絡先からのやり取りをリアルタイム通知する機能です。通知をクリックしたときに開く詳細パネルに、ウィジェットを表示できます。
外部のコミュニケーションツールと連携し、通知の中身をCRM内で確認・返信できるようにする、といった用途が想定されたタイプです。8種類のなかでは利用頻度が低く、拡張機能(エクステンション)開発でのユースケースが中心になります。
7. 設定画面ウィジェット
Zoho CRMの設定画面内にコンポーネントとして表示するタイプです。
主にエクステンションで、インストール後の設定UI(APIキーの登録、同期対象の選択、マッピング設定など)を提供するために使われます。自社1社向けのカスタマイズよりも、配布を前提とした拡張機能開発で意味を持つタイプです。
8. ブループリントウィジェット
ブループリントは業務プロセスをCRM上で再現する機能で、その遷移(トランジション)中にウィジェットを表示できます。
遷移時に複雑な入力や外部システムへの照会が必要な場合、標準の遷移項目では対応しきれません。そこにウィジェットを挟むことで、条件確認や外部データの取得をプロセスに組み込めます。
注意点として、1つの遷移に関連付けられるウィジェットは1つだけです。また、JS SDKの ZOHO.CRM.BLUEPRINT.Proceed を使って、ウィジェット側から遷移を進める処理を実装します。
モバイルアプリで表示できるタイプ
ウィジェット作成時のポップアップ下部に「Mobile Compatibility」の設定があり、有効にするとモバイルアプリでも表示されます。ただし対応しているのは以下の5タイプのみです。
- 関連リスト
- Webタブ
- ボタン
- ブループリント
- ウィザード
ダッシュボード・シグナル・設定画面のウィジェットは対象外です。また、モバイル対応にするためのUI調整(レスポンシブ対応など)はウィジェット側の責任で、フラグを立てるだけで自動的に最適化されるわけではありません。エクステンション経由のウィジェットにはこのモバイル対応が適用されない点にも注意が必要です。
なお、コンポーネントにウィジェットを関連付ける際、モバイル非対応のウィジェットにはアイコンが表示されるため、設定画面上で判別できます。
作成と設置の流れ
ウィジェットの登録手順は、タイプによらず共通です。
- [設定]>[開発者向け情報]>[ウィジェット]を開く
- [ウィジェットを作成]をクリックする
- 名前(必須)と説明(任意)を入力する
- ウィジェットタイプを選択する
- ホスティング方法を選択する
- 保存する
ホスティングの2方式
内部ホスティング(Zoho) アプリケーションをZIPで固めてアップロードし、CRM内のインデックスURLを指定します。Zohoのサーバー上でホストされるため、別途サーバーを用意する必要がありません。自社用に作ったウィジェットは基本的にこちらで十分です。ZIPの上限は25MBです。
外部ホスティング 自前のサーバーやホスティングサービスに置いたアプリのURLを指定します。ビルドパイプラインを回してデプロイしたい場合や、サーバーサイド処理を含む場合はこちらになります。
開発時は、Zoho CLI(zet init など)でプロジェクトの雛形を作り、ローカルで動作確認してからパッケージ化する流れが標準です。ZDK CLIを使えば、ウィジェットの設定をJSONとして取得してバージョン管理下に置いたり、他組織へエクスポートしたりできます。
JS SDKの基本
ウィジェット内では、Embedded App SDKを読み込んで初期化します。
// イベントリスナーを登録してから初期化する
ZOHO.embeddedApp.on("PageLoad", function (data) {
console.log(data);
});
ZOHO.embeddedApp.init();
PageLoad はエンティティのページが読み込まれたときに発生し、ここでタイプごとに異なるコンテキスト情報を受け取ります。関連リストなら Entity と EntityId、ボタンなら EntityId の配列と ButtonPosition といった具合です。
リスナーの登録は init() より前に書く必要があります。順序を逆にするとイベントを取りこぼすため、動かないときはまずここを疑ってください。
APIヘルパーはPromiseベースで提供されており、レコード取得やCOQLクエリの実行などが可能です。
ZOHO.CRM.CONFIG.getCurrentUser().then(function (data) {
console.log(data);
});
制限と運用上の注意点
| 項目 | 内容 |
|---|---|
| 利用可能プラン | エンタープライズ、アルティメットのみ |
| 作成できるウィジェット数 | 最大200(エンタープライズ/アルティメット) |
| ZIPファイルの上限 | 25MB |
| ブループリント遷移あたりのウィジェット | 1つのみ |
| モバイル対応タイプ | 関連リスト、Webタブ、ボタン、ブループリント、ウィザード |
削除時は設置先を先に外す ウィジェットを削除する前に、関連付けられているレイアウト、ボタン、Webタブ、ウィザードなどの設置先を解除しておく必要があります。設置されたまま消そうとすると整合性の問題が起きます。
エクステンション由来のウィジェットは直接消せない マーケットプレイスからインストールした拡張機能のウィジェットは、ウィジェット画面から削除できません。拡張機能自体をアンインストールすると、自動的に取り除かれます。
内部ホスティングのウィジェットはダウンロードできる ウィジェット詳細にカーソルを合わせて表示される設定アイコンから[ダウンロード]を選ぶと、アップロードしたパッケージを取得できます。ソースを失ったときの保険にはなりますが、本来はGitなどで管理しておくべきです。
Canvas・クライアントスクリプトとの使い分け
Zoho CRMには画面をカスタマイズする手段が複数あり、ウィジェット以外にもCanvasとクライアントスクリプトがあります。作る前に、どれで足りるかを判断しておくとコストを抑えられます。
| 手段 | 性質 | 利用可能プラン |
|---|---|---|
| Canvas | 標準画面(リストビュー・詳細ビュー・フォームビュー)のデザインをノーコードで差し替える | スタンダード以上 |
| クライアントスクリプト | 標準画面上でJavaScriptによる制御・バリデーションを行う | エンタープライズ以上 |
| ウィジェット | 独自のUIコンポーネントを作り込んで埋め込む | エンタープライズ以上 |
大まかな判断基準としては、見た目を整えたいだけならCanvas、標準画面の挙動を制御したいならクライアントスクリプト、標準画面の構造そのものでは表現できないUIが必要ならウィジェット、という順で検討するのが現実的です。ウィジェットは自由度が高いぶん、保守コストとホスティングの管理が発生します。
まとめ
Zoho CRMのウィジェットは8種類あり、設置場所ごとに受け取れるコンテキストとSDKの使い方が変わります。
- 特定レコードに紐づけたいなら 関連リスト(
Entity/EntityIdが渡る) - 複数レコードへの一括処理や入力ダイアログなら カスタムボタン(IDが配列で渡る)
- 独立した1画面のアプリなら Webタブ
- KPIや独自の可視化なら ダッシュボード
- プロセスに組み込むなら ウィザード または ブループリント
- 拡張機能の配布が前提なら 設定画面 や シグナル
最初にタイプを間違えると作り直しになるため、「どこに置くか」「何のデータが必要か」を決めてから着手するのが結局いちばん早い進め方です。