失注した商談には理由を残してほしい。期限が近い案件を一覧で見つけたい。重要な条件に当てはまる顧客には、対応前に確認事項を伝えたい。こうしたルールを、口頭説明やマニュアルだけで共有していないでしょうか。

IPBusinessRules（業務ルール設定）は、条件に応じて「表示・入力制御」「一覧の色分け」「注意メッセージ」を設定する、vtplusのノーコード活用を支えるエクステンションです。

管理者が一つのルールに条件を設定し、必要な動作を組み合わせます。例えば「営業ステージが失注」という条件で、失注理由を表示・必須化し、一覧の背景色を変え、確認メッセージを表示する構成が作れます。

この記事では、3機能の詳細、条件や優先順位の考え方、具体的な設定例、適用される画面、保存時の検証までを解説します。

1．IPBusinessRulesとは？条件に応じた画面の動きを設定する

IPBusinessRulesは、「どの条件のとき、どのような動作をさせるか」を管理画面から設定するエクステンションです。表示だけ、色分けだけ、注意メッセージだけを使うルールも、3種類を組み合わせるルールも作れます。

入力のルールを、必要な場面で伝えられる

すべての項目を常に表示し、すべてを必須にすると、対象外の作業まで入力する負担が増えます。状況に応じて項目を表示し、必要なときに入力を求めることで、業務上の区別を画面に反映できます。

一覧では条件に合うレコードを見つけやすくし、注意メッセージではその場で確認してほしい内容を伝えます。業務ルールを覚えることだけに頼らず、入力・確認の場面に支援を置く考え方です。

メール送信や承認を実行するワークフローとは役割が異なる

この版が扱うのは、表示・入力制御、一覧の色分け、注意表示です。メール送信、承認、タスク作成、項目値の更新などのワークフロー機能は含みません。

例えば「高額案件に注意を表示する」と「高額案件を上長へ承認依頼する」は別の処理です。後者が必要な場合は、標準のワークフローや対応する拡張などと役割を分けて検討します。

2．条件の設定：文字・数値・選択肢・日付を使い分ける

ルールには名前、対象モジュール、優先度、条件、動作を設定します。条件では、比較する項目、比較方法、必要な比較値を指定します。

利用する比較方法は、項目の型に合わせて選びます。日付・日時では対応する演算を使い、日付の設定値はYYYY-MM-DD、日時はYYYY-MM-DD HH:MM:SS、数値はカンマなしの半角数値で指定します。

表示ラベルと、実際の保存値を区別する

選択リストには、画面に見える日本語ラベルと内部で保存される値が異なるものがあります。条件の比較にはCRMの実際の保存値を使います。管理画面で選択肢を指定するときも、対象の項目と値が意図した内容かを確認します。

複数選択項目では、選択値のいずれかとの一致を判定します。「候補のいずれか」などで複数の比較値を指定する場合は、一行に一つずつ入力します。

複数条件はANDまたはORで組み合わせる

ANDは「すべての条件に合う」、ORは「いずれかの条件に合う」という意味です。例えば「対応期限が今日から7日以内」かつ「状態が未完了」という対象は、必要な項目と値を準備し、ANDで設定する考え方になります。

一つのルールで複雑な括弧付きの条件式を自由記述する方式ではありません。AND／ORで表せない組み合わせは、ルールを分けるなど、優先順位を含めて設計します。

空欄、0、チェックOFFには違いがある

空欄は、通常の不一致や大小比較にも一致しません。「完了ではない」という不一致条件だけで、未入力も対象になるとは考えないようにします。未入力を対象に含める場合は、専用の「空欄」条件を使います。

数値の0とチェックOFFの0は空欄ではありません。また、文字列は前後の空白を除いて比較し、大文字・小文字を区別します。コードや区分を条件にするときは、入力値の形式も確認します。

日付の「今日」と、期限を過ぎた日付の扱い

「今日」はログインユーザーのタイムゾーンで判定します。「今日から7日以内」は今日から7日後までの範囲で、過去の日付を含みません。指定できる日数は0〜3650日です。

「今日以前」は今日も含みます。期限が今日のものを含めて注意したいのか、過ぎたものだけを扱いたいのかを分け、条件名と案内文をそろえましょう。

3．表示・入力制御：必要な項目だけを示し、条件付きで入力を求める

表示・入力制御では、項目の表示・非表示、追加の必須入力、読み取り専用を設定します。ブロック単位では、見出しとその中の項目をまとめて表示・非表示にできます。

「一致したとき」と「それ以外」の動きを設定する

例えば失注理由なら、条件に一致したときに表示・必須、それ以外は非表示・追加した必須条件を解除、と指定します。画面には「この条件のときだけ表示」「この条件のとき必須」など、よく使う設定を選ぶ補助があります。

入力中の変更はブラウザー内で判定し、対応する画面へ反映します。自動入力など他の処理で値が変わる場合も変更の検知を行いますが、実際の他拡張との組み合わせは対象環境で確認します。

表示を切り替えても、入力済みの値を消さない

非表示になった項目の値を、自動で空欄にする機能ではありません。例えば失注理由を入力した後にステージを戻しても、非表示に切り替わることと、保存済みの理由を消すことは別です。

見えなくした値を帳票・外部連携などで使う場合は、非表示のまま保持されることを前提に、業務上の扱いを決めます。

標準の必須設定・アクセス権限を解除する機能ではない

「追加した必須条件を解除」「追加した読取専用を解除」は、この拡張が追加した制限の解除です。CRM標準の必須設定やアクセス権限は維持します。

標準必須項目の非表示・任意化、標準必須を含むブロックの非表示、条件に使う項目やそのブロックの非表示は、設定時に拒否します。判定に必要な項目を隠し、利用者が操作できなくなる構成を避けるための制約です。

必須・非表示・読み取り専用が重なったとき

追加必須と非表示が重なった場合は、必須入力を優先して表示します。必須項目が空欄なのに読み取り専用になる場合も、入力できる状態を保つ扱いがあります。

読み取り専用は詳細画面の編集操作にも反映し、既存レコードの保存時に値の変更を検証します。ただし、条件を編集できるかどうかを含めた業務全体の権限設計は別途必要です。変更できない記録を保証する承認・確定管理として、そのまま代用するものではありません。

4．一覧の色分け：対応が必要なレコードを見つけやすくする

一覧の色分けでは、条件に一致するレコードの行背景、指定項目の背景色・文字色を設定できます。例えば期限が近いものは薄い黄、特定の確認が必要なものは淡い赤など、社内で色の意味をそろえて使います。

一覧にない条件項目でも、閲覧権限があれば判定できる

条件項目そのものが一覧の表示列になくても、閲覧権限があれば保存済みの値で判定します。一方、色を付ける対象の項目は、一覧に表示されている場合に反映します。

一覧を更新したときは、元のスタイルを復元してから色を付け直します。入力画面で編集途中の未保存値が、別の一覧へそのまま反映されるものではありません。

対象は通常一覧の、表示されている先頭100件

この版は標準の通常一覧を対象とし、表示されている最初の100件を判定します。カンバン、関連一覧、ポップアップ、ダッシュボードなどを専用の対象画面として扱うものではありません。

色だけに意味を持たせると、見分けにくい利用者もいます。状態や期限などの文字情報を残し、背景色と文字の読みやすさを確認しましょう。色分けを増やす前に、重要な2〜3種類の意味から整理すると運用しやすくなります。

5．注意メッセージ：対象者とタイミングに合わせて案内する

注意メッセージは、条件に合うレコードや入力内容について、利用者へ確認事項を伝える機能です。タイトル、本文、表示方法、重要度、タイミング、対象者、再表示頻度などを設定します。

4種類のタイミングから選ぶ

保存後と詳細を開いたときの両方を指定した同じルールは、保存直後の判定で重複しないように扱います。必要なタイミングだけを選び、同じ案内を過剰に繰り返さない設定を検討します。

注意メッセージの対象者を選ぶ

対象者には、全員、指定ロール、指定ユーザー、指定ロールまたは指定ユーザーを設定できます。指定ロールに下位ロールを含める選択もあります。

この対象者設定は、注意メッセージにだけ適用します。同じルールの表示・入力制御や色分けまで、指定した人だけに限定する設定ではありません。表示制御・色分けには通常のモジュール・項目の権限を適用します。

再表示頻度で、繰り返す案内を調整する

• 条件に一致するたびに表示
• ブラウザーセッションで1回
• レコードごとにブラウザーセッションで1回
• ユーザー・レコードごとに1日1回
• ユーザー・レコードごとに初回のみ

セッション方式はタブのsessionStorageを使います。すべてのタブや端末で、共通して一度だけ表示されるという意味ではありません。1日1回・初回のみの方式では、CRM側に表示履歴を保存します。ルール内容を変更すると、新しい定義として再表示の対象になります。

重要度・差し込み・ボタンなども設定できる

重要度は「情報」「完了・正常」「警告」「重要・エラー」から選びます。確認ボタンの名前、閉じる可否、トーストの表示秒数3〜60秒も設定できます。短時間で消える表示には、読める量の文章を使います。

タイトルと本文には、{record_label}、{module_label}、{record_id}、{field:amount}などを差し込めます。amountは実際の項目内部名に置き換え、対象者が閲覧できない項目の内容は表示しません。

タイトル・本文はプレーンテキストです。HTMLを使った自由な装飾やスクリプト実行を行う形式ではありません。

表示履歴は、業務上の承認・同意の記録ではない

メッセージが表示されたことと、利用者が業務内容を確認・承認したことは同じではありません。「確認しました」というボタン名にしても、業務上の承認や同意を証明する仕組みにはなりません。

注意表示は、通常の保存を止める業務承認機能ではありません。情報の入力を求めたいときは条件付き必須を組み合わせ、承認者の判断を記録したいときは別の業務機能を検討します。

6．設定例：失注時の理由入力と、確認の案内

ここでは、商談の営業ステージが失注に該当した場合、理由の入力を求める例を紹介します。前提として、失注理由の項目を標準レイアウトエディターなどで用意します。

管理画面の設定例を使い、実際の項目を指定する

「失注理由の設定例」は、条件や表示動作を準備する入口です。対象の理由項目を選び、自社のステージの値と一致するかを確認します。必要な色分けと注意メッセージを追加し、設定を保存します。

条件に一致する場合と、一致しない場合を試す

編集画面でステージを変更し、理由欄の表示・必須が切り替わるか、理由が空欄の場合に保存を求められるかを確認します。入力済みの理由を残したまま別のステージへ戻し、値が消えないことも確かめます。

一覧の色は保存後に確認します。編集途中の値変更で注意を出したい場合は、そのタイミングを選びます。詳細画面だけの設定では、同じように入力途中へ表示されるとは限りません。

7．複数ルールの優先順位を、属性ごとに考える

同じ項目に複数のルールが関係する場合は、優先度を設定します。0〜9999の範囲で、数値が大きいルールを優先します。

優先順位は、表示、必須、読み取り専用、色分けの対象・種類ごとに扱います。「優先度の高いルールが一件選ばれ、それ以外の動作がすべて消える」という意味ではありません。

「変更しない」は、元の状態へ戻すという意味ではない

ある属性を「変更しない」にすると、その属性については他ルールの設定を引き継ぎます。例えば、あるルールが表示を指定し、別のルールが必須だけを指定すると、両方の属性が反映される構成があります。

同じ優先度では、ルールIDの辞書順で後のものを優先します。業務上の優先を明確にしたいルールには、異なる数値を指定する方が管理しやすくなります。

注意メッセージは、複数の一致結果を表示する

複数の注意メッセージが条件に一致した場合は、優先度順に表示します。色分けや表示制御と同じ感覚で「一つだけが残る」と考えず、同時に出る案内の数も確認します。

例外のルールを追加する際は、通常のルールと併せて動作を確認し、「どの場面で何が優先されるか」をルール名や管理メモから判断できるようにしておきます。

8．管理者の設定手順と、保存済みルールの判定確認

入口は、CRM設定 → その他の設定 → 業務ルール設定です。設定の閲覧・変更・診断は管理者専用で、一般利用者は通常の業務画面で設定結果を利用します。

判定確認は、保存済みの値に対して行う

ルールを保存して選択し、「保存済みルールの判定確認」へ同じモジュールのレコードURLまたはIDを入力して「判定を確認」を押します。条件の一致と、項目権限による対象外を確認できます。

ここでの結果は、入力途中の未保存値や、すべての対象ユーザーの表示結果を代わりに確認するものではありません。注意メッセージの対象者・再表示頻度と、具体的な画面表示は、実際の対象ユーザーと画面でも確認します。

複製・JSONの書き出し・読み込みを利用できる

似たルールは複製して編集できます。複製直後は誤適用を避けるため無効の状態なので、条件と対象を確認してから有効にします。

設定のJSON書き出し・読み込みは、この製品の設定形式に対応します。項目名やモジュールが異なる環境へ、そのまま無条件に適用できるとは限りません。読み込んだ後に内容を確認し、「設定を保存」で確定します。

ルールは100件、一ルール当たり条件20件、表示動作50件、色分け20件以内です。設定JSONは500KB以内という制約もあります。ルールを増やす前に、同じ目的の設定が重なっていないかを整理します。

全体・機能・ルールごとに有効・無効を切り替える

画面上部で全体と3機能をそれぞれ切り替え、個別のルールも無効にできます。切替や削除は「設定を保存」で確定します。同時編集を検出した場合は、他の設定を上書きせず保存を拒否します。

インストール時はルール0件です。機能が有効でも、ルールを設定するだけでなく保存して適用する必要があり、インストールだけで業務画面が変わるものではありません。

9．対象画面・保存経路・権限を確認する

保存検証は、すべての書き込み経路へ一律ではない

追加必須と読み取り専用の保存検証は、vtiger.entity.beforesave.finalイベントを通る経路が対象です。通常のAPIなどでもそのイベントが実行される場合は検証しますが、画面が同じように表示されることとは別です。

直接SQLで更新する処理や、通常の保存イベントを経由しない一括処理には適用できません。CSVインポートや独自連携なども含め、利用する保存経路ごとに動作を確認します。あらゆる経路の入力制約を自動で統一する機能として扱わないようにします。

条件に使う項目の権限も、判定に関係する

条件項目の閲覧権限がない場合は、否定条件やORを使っていても、そのルールを判定対象から外します。「値が見えないから不一致として処理する」という扱いではありません。

項目の非表示設定はアクセス権限の代わりではありません。機密情報を見せない目的はCRM標準の権限で管理し、この拡張の表示制御は業務画面を整える用途として設計します。

設定変更・機能停止の後は、画面を読み直す

設定を保存するとサーバー側の判定・検証へ反映しますが、開いている業務画面には読み込み済みの設定が残るため、対象画面を再読み込みします。

標準アンインストールでは設定・表示履歴を保持します。対応する管理ツールからの完全削除では、専用の設定・表示履歴テーブル2個を削除対象とします。機能停止、アンインストール、完全削除の目的を分けて管理します。業務レコードや標準フィールドを削除する操作ではありません。

10．業務での応用と、vtplusの他機能との役割分担

期限が近いレコードの確認

対応期限と状態の項目がある場合、今日から指定日数以内かつ未完了などの条件を作り、一覧の色と注意を設定します。期限を過ぎたものも対象にするなら、その条件も分けて設計します。

一定金額以上の案件の確認

例えば金額が1,000,000以上という条件で、確認理由の追加必須や「見積内容と社内確認事項を確かめてください」という案内を組み合わせる構成です。金額は設定例であり、製品が推奨する基準ではありません。社内承認は別の処理として扱います。

特定の受付区分だけ、追加情報を入力する

問い合わせの区分に応じて、利用環境や発生条件のブロックを表示するなど、必要な項目を用意したうえで使えます。ブロックに標準必須項目や条件項目が含まれる場合は、非表示の制約を確認します。

IPModuleMaker・IPInputAssistと、設計の役割を分ける

IPModuleMakerは、業務モジュール・関連・項目・明細など、管理する情報の構造を作る役割です。IPInputAssistは、記入例、関連情報の自動入力、候補選び、書式、住所入力などを支える役割です。

IPBusinessRulesは、その情報の条件に応じた表示・入力制御、色分け、注意表示を設定します。組み合わせる場合も、各機能の対象モジュール・項目・画面を確認します。すべての拡張が無条件に併用できるという意味ではありません。

11．IPBusinessRulesについて、よくある質問

3機能を、すべて使う必要がありますか？

ありません。一つのルールに必要な動作だけを設定できます。表示動作のない、色分け専用や注意メッセージ専用のルールも作れます。

注意メッセージの対象者を絞ると、表示制御もその人だけになりますか？

なりません。ロール・ユーザーの対象指定は注意メッセージ用です。表示・入力制御と色分けには、通常のモジュール・項目権限を適用します。

非表示にした項目の値は削除されますか？

削除しません。表示を切り替えても値を保持します。機密情報へのアクセスを禁止する場合は、標準の権限を設定します。

確認ボタンを押したことを、承認記録として使えますか？

表示履歴は業務上の承認・同意の証跡ではありません。承認者や承認状態を管理する要件は、別の機能として設計します。

同じルールの注意が、何度も出ることを減らせますか？

再表示頻度を、セッション、レコードごとのセッション、ユーザー・レコードごとの1日1回や初回のみなどから選べます。タブや端末の違い、ルール定義の変更も踏まえて確認します。

導入時に、サーバーの追加設定は必要ですか？

同梱資料の対象はPHP 8.1以降、mbstring、およびVtiger標準の実行要件です。コアファイルの自動上書き、追加Cron、サーバー常駐処理、外部サービスへの通信はない構成です。CRM環境へのインストールと設定保存が必要なので、バックアップを取り、テスト環境で確認します。

実環境での動作確認は、どこまで行われていますか？

本記事は添付版のコード・資料を照合したもので、記事作成時に稼働CRMへインストールしたものではありません。同梱の検証資料も、検証用のモデル・権限・イベントやDOMでの確認と、実CRM・実ブラウザー・実保存経路・他拡張との実機併用の未確認範囲を分けています。利用環境で管理者と一般利用者の双方から確認します。

まとめ｜業務上の条件を、入力と確認の支援へつなげる

IPBusinessRulesは、表示・入力制御、一覧の色分け、注意メッセージの3機能を備えた、vtplusの業務ルール設定エクステンションです。一つの条件をもとに、必要な場面へ入力の制約や確認の案内を配置できます。

まずは「どの状態で何を入力してほしいか」「一覧で何に気付いてほしいか」「誰に、いつ確認を促したいか」を一つずつ整理してみてください。条件と画面の動きを具体化することで、自社に合う設定を検討しやすくなります。