目次
Zoho CRMは、標準機能のままでも使えますが、実際の業務に合わせようとすると必ずカスタマイズの話になります。案件ごとの明細を持たせたい、合計金額を自動で出したい、外部システムとつなぎたい——このあたりから、画面上では見えない仕様に当たり始めます。
実案件でZoho CRMを設定していく中で、私たちも同じところでつまずきました。いずれも「技術力」の問題ではなく、先に知っていれば設計を変えられたタイプの仕様です。
この記事では、その3点と、設定を始める前に決めておくべきことを整理します。なお、SaaSの仕様は変わるため、数値や条件の最新情報は必ず公式ドキュメントで確認してください。
この記事の結論
- サブフォームは数に上限があり、明細を増やす設計は途中で詰む
- 削除しても枠は解放されない。見た目と上限判定は一致しない
- API名は日本語ラベル任せにせず、最初に英字で決める
落とし穴1：サブフォームの上限で明細設計が行き止まりになる
Zoho CRMのサブフォームは、1件のレコードの中に明細行をぶら下げられる便利な仕組みです。案件に対する商品明細、作業報告に対する作業項目——業務システムらしい形を作るときに、まず使いたくなる機能です。
ところが、1つのモジュールに追加できるサブフォームの数には上限があります。
これが問題になるのは、「明細を複数種類ぶら下げる」設計をしたときです。1つの案件に対して、商品明細・作業明細・費用明細……と種類を分けていくと、途中で追加できなくなります。しかも上限に当たるのは、たいてい設計が固まって作り込みが進んだ後です。
対策は単純で、先に必要な明細の種類をすべて洗い出すこと。上限に収まらないなら、サブフォームを分けるのではなく、行に「種別」の列を持たせて1つのサブフォームにまとめる、あるいは別モジュールに切り出して関連付ける、という設計に切り替えます。作り始めてからの方針転換は、それまでの設定がほぼ作り直しになります。
落とし穴2：枠が解放されない原因は「見た目」と「判定」のズレ
上限に当たったとき、多くの人が最初にやるのは「使っていないサブフォームを消す」ことです。ところが、ここで二重につまずきます。
行や項目を「×」で削除しても、枠がすぐには解放されないことがあります。画面上は消えているのに、システム側の上限判定では数え続けている状態です。つまり、見た目の数と、追加できるかどうかの判定が一致しません。
この状態で「消したのに追加できない」と何度も試すと、原因の切り分けに時間を溶かします。私たちも、設定ミスを疑って同じ操作を繰り返しました。
覚えておくべきことは1つです。サブフォームは、作って消して調整する前提で扱わない。削除で枠が戻る前提の設計は成立しません。最初に全体像を決めてから作る、これに尽きます。
落とし穴3：数式フィールドはサブフォームを集計できない
3つ目は、合計金額のような「明細を足し上げた値」を出したいときの話です。
Zoho CRMには数式フィールドがありますが、数式フィールドはサブフォームの値を集計できません。同じレコード内の通常フィールド同士の計算はできても、サブフォームの行を縦に足す用途には使えない、という仕様です。
明細の合計を親レコードに持たせたい場合は、Rollup系の集計機能を併用します。「数式でできるだろう」と見込んで設計を進めると、合計欄を作る段階で手詰まりになります。
| やりたいこと | 使う機能 | 注意点 |
|---|---|---|
| 通常フィールド同士の計算 | 数式フィールド | サブフォームは参照できない |
| サブフォーム明細の合計 | Rollup系の集計機能 | 集計対象と条件を先に決める |
| 明細を複数種類持つ | サブフォームの分割／種別列 | 数の上限を先に確認 |
合計を出す要件は、ほぼすべての業務で発生します。見積・請求まわりを作るなら、集計方法は最初に決めるのが安全です。
Zoho CRMのAPI名が「field1」になる原因と対策
ここまでは画面設定の話ですが、外部連携まで見据えたときに一番効いてきたのが、API名の問題でした。
Zoho CRMでフィールドを作るとき、ラベルを日本語で入力すると、API名がfield1、field2のように自動採番されます。画面上は「取引先担当者名」「成約予定日」と正しく表示されるので、設定作業中は何の問題もありません。
問題が出るのは、外部システムとつないだときです。連携のコードから見えるのはAPI名だけなので、field1、field7、field12といった記号の羅列になります。何の項目か分からない。仕様書と突き合わせないと読めない。数か月後の改修時に、当時の担当者でも判別できない——という状態になります。
対策：フィールド作成時に英字のAPI名を明示する
私たちはこの一件以降、フィールドを作る前にAPI名の命名ルールを決める運用に変えました。
- 項目一覧を先に作り、日本語ラベルと英字API名をセットで決める
- フィールド作成時に、API名を手動で英字指定する
- 作成後にAPI名を変えない（連携側の修正が発生するため）
後からAPI名を整理し直すのは、連携コードの書き換えとテストをまとめて抱えることになり、最初にやる手間とは比較にならない負担になります。ここは設定開始前の10分で決まる話です。
Zoho CRM設定の進め方：作り始める前に決める3つ
3つの落とし穴に共通するのは、どれも「作り始めてから直す」のが高くつくという点です。順序を変えるだけで、ほとんどは避けられます。
- 明細の種類をすべて洗い出す：後から増やす前提にしない。上限に収まるか、1つにまとめるかを先に判断します。
- 集計方法を決める：合計を出す項目をリストアップし、数式で足りるのか、Rollup系が必要かを分けておきます。
- API名の命名ルールを決める：外部連携の予定が「今はない」場合でも決めておきます。後から連携要件が出るのが普通だからです。
この3つを先に決めておけば、設定作業そのものは素直に進みます。逆にここを飛ばすと、画面を作りながら仕様に当たり、そのたびに前に戻ることになります。
よくある質問
Q. Zoho CRMのサブフォームはいくつまで作れますか？ 1つのモジュールに追加できるサブフォームの数には上限があります。具体的な数はプランや時期で変わるため、設計前に公式ドキュメントで最新の条件を確認してください。上限に達すると明細の追加自体ができなくなります。
Q. サブフォームを削除したのに上限に達したと表示されるのはなぜですか？ 削除操作をしても枠が即座に解放されない場合があるためです。見た目の数と、システムが数えている数は一致しません。作り直して調整するのではなく、最初に必要な明細の種類を洗い出してから設計してください。
Q. Zoho CRMでフィールドのAPI名がfield1になるのを防ぐには？ 日本語ラベルだけでフィールドを作ると、API名がfield1、field2のように自動採番されます。フィールド作成時にAPI名を英字で明示的に指定する運用に変えれば防げます。後からの変更は連携側の修正を伴うため割高です。
まとめ
- サブフォームには数の上限があり、明細を種類ごとに増やす設計は途中で行き止まりになる
- 「×」で削除しても枠が解放されないことがあり、見た目と上限判定は一致しない
- 数式フィールドはサブフォームを集計できず、合計を出すにはRollup系の併用が必要
- 日本語ラベルだけで作るとAPI名が自動採番される。設定前に英字のAPI名を決める運用に変えると、後の連携が読める状態で残る
- 仕様は変わるため、上限値などの最新条件は必ず公式ドキュメントで確認する
RENOYでは、CRMやSaaSの設定・カスタマイズを、外部連携まで見据えた設計から支援しています。「入れたけれど業務に合わない」「作り込んだ後で行き詰まった」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。