Salesforce の入力規則の作り方と気をつけること

入力規則でできること

入力規則は、レコードを保存する前に、入力された値が決めた条件に合っているかを確かめる仕組みです。条件は数式で書き、数式が「True」を返したときに、その値を誤りとして扱います。[1][2]

誤りがあると、決めておいたエラーメッセージが出て、レコードは保存されません。1 つの規則に引っかかっても残りの規則の確認は続き、エラーはまとめて表示されます。[1][5]

使いどころは、値の形式や範囲をそろえたいときです。たとえば、電話番号の形式をそろえる、割引率に上限を設けるといった使い方が公式の教材で紹介されています。[2]

作るときは、オブジェクトマネージャーで対象のオブジェクトを開き、[入力規則] から [新規] を押します。数式を書いたら、[構文を確認] で数式の誤りを確かめてから保存します。[2]

数式とエラーメッセージの決め方

数式は「保存させたくない状態」を書きます。条件を満たすと保存を止める、という向きで考えると迷いにくくなります。比べる式はそのまま書けば足り、IF で TRUE と FALSE を返す形にする必要はありません。[2][4]

エラーメッセージには、どう直せば保存できるかを書きます。公式のヒントでは、正しい値の種類を伝えること、どの項目の誤りかが分かるよう項目の表示ラベルを入れることが勧められています。[4]

表示する場所は、項目の下か、ページの上部かを選べます。項目の下に出すと、どこを直すかが一目で分かります。ただし、表示場所に選んだ項目が後で削除されたり、参照のみやページレイアウトに無い状態になったりすると、表示場所はページの上部に切り替わります。[3][4]

2026年10月時点では、[ページの最上部] を選んだ規則のエラーは、Lightning Experience ではページの下部に出ます。画面の上だけを見ていると気づかれにくいため、メッセージに項目名を入れておくと親切です。[3][4]

規則名とエラーメッセージに同じ番号を付けておくと、利用者から届いたエラーがどの規則のものかを探しやすくなります。[4]

よく使う関数の例

関数の使い方は、公式ヘルプの入力規則の例が参考になります。用途別に例が並んでいて、自社の項目に合わせて変えて使えます。主な関数は次のとおりです。[10][6]

• ISBLANK は、値が空かどうかを調べます。空のときに TRUE を返します。[6]
• ISPICKVAL は、選択リストの値が指定した値と同じかを調べます。商談のフェーズに応じて項目を必須にする例で使われています。[6][7]
• ISNEW は新規作成のときに、ISCHANGED は項目の値が変わったときに TRUE を返します。作成時や変更時だけ確かめたいときに組み合わせます。[6][7]
• PRIORVALUE は、項目の前の値を返します。前の値と今の値を比べる条件を書くときに使います。[6]
• REGEX は、テキストが正規表現の形式に合うかを調べます。番号の桁や形式をそろえたいときに向いています。[6][10]

空の値の扱いには注意が要ります。BEGINS や CONTAINS を使う規則では、空の項目は有効と判断されます。空も誤りにしたいときは、ISBLANK を OR でつなぎます。[4]

ほかの必須の方法との違い

「この項目は空で保存させない」という決まりは、入力規則以外の方法でも作れます。どの経路の保存に効くかが違います。[8][9]

• 方法 1項目の必須カスタム項目の設定で [必須] にします。画面や API からの保存で値が要ります。ただし、簡易作成では必須項目が強制されず、必須にする前からあるレコードは空のままでも残ります。標準項目には使えず、すべてのレコードタイプで必須になります。[8][9]
• 方法 2ページレイアウトの必須レイアウト上で必須にします。2026年10月時点の実行順序の説明では、レイアウト固有のルールは標準の編集画面からの保存でだけ確かめられます。[9]
• 方法 3入力規則条件付きの必須を書けます。フェーズが進んだときだけ必須にする、といった決まりに向いています。API からの保存にも効きます。[1][7]
• 方法 4ルックアップ検索条件ルックアップで選べる候補を絞ります。親の項目を使うなど、数式が要る複雑な条件は入力規則のほうが向いています。[5]

取り込み・API・自動化との関係

入力規則は、画面からの保存だけでなく、API による作成と更新にも効きます。参照する項目が API コールに含まれていなくても、規則は確かめられます。データの一括取り込みや外部システムとの連携があるオブジェクトでは、それぞれの経路で規則に引っかからないかを確かめておきます。[1]

一方で、規則が動かない経路もあります。ワークフロールールの項目自動更新や、プロセスのスケジュール済みアクションによる更新では、入力規則は実行されません。所有権の一括移行で複数のレコードの所有者を変えたときも同じです。キャンペーン階層でも規則は無視されます。[5][9]

2026年10月時点の実行順序では、保存前に動くレコードトリガーフローと before トリガーの後に、入力規則が実行されます。保存前の自動化で入れた値も、入力規則の対象になります。[9]

Web-to-リードと Web-to-ケースでは、レコードを作る前に入力規則が実行され、規則に合う値を持つレコードが作られます。フォームの項目と規則の条件を合わせておきます。[5]

作った後のテストと、規則が増えたときの見直し

設計の甘い規則は、正しいデータまで保存できなくすることがあります。公式のヒントでは、有効にする前にテストし、デバッグログで動きを確かめるよう案内されています。[4]

テストでは、規則に合う値と合わない値の両方で保存してみます。ページレイアウトが複数あるオブジェクトでは各レイアウトで、連携があるオブジェクトでは各連携で動くかを確かめます。割り当てルールや項目自動更新、項目レベルセキュリティ、非表示の項目など、規則に引っかかるおそれのある設定も合わせて見ます。[1][4]

既存のレコードは、規則を有効にした時点では確かめられません。規則は新しいレコードと更新されたレコードに適用されるため、古いレコードを編集したときに初めてエラーになることがあります。[1]

規則が増えると、同じ項目に矛盾する規則が重なり、どう入力しても保存できない状態が生まれることがあります。各規則の説明欄に目的を書き、使わなくなった規則は [有効] を外して止めておくと、見直しが楽になります。[4][3][11]