Salesforceのフローで重複チェックしてレコードの二重作成を防ぐ例｜ブログ

なぜ重複作成を止めたいのか

営業担当者が同じ取引先名で何度もレコードを作ってしまうと、商談や活動が分散し、履歴が追えなくなります。この問題は、フローを自作する前に確認すべき標準機能があります。

まず結論です。取引先・取引先責任者・リード・個人取引先の重複を防ぐだけなら、標準の重複ルールと一致ルールで足ります。フローが必要になるのは、対象オブジェクトが違う場合や、独自の判定条件を保存前に必ず通したい場合です。

標準の重複ルールでできること

重複ルールは、セットアップで「重複ルール」と検索して設定します。一致ルールで「似ているレコード」の判定基準を決め、重複ルールでその判定が起きたときの動作を決める仕組みです。

アクション	動作
警告	重複の可能性を通知しつつ、ユーザーの判断で保存を続行できる
ブロック	重複と判定されたレコードの保存を完全に禁止する
許可	警告を出さずにそのまま保存する

標準の重複ルールは、ビジネス用の取引先・取引先責任者・リード・個人取引先（有効化後）を対象に用意されています。Summer '17より前に作成された組織では、標準ルールが既定で有効です。

重複ルールは、すべての保存経路で必ず働くわけではありません。クイック作成、Experience Cloudサイトのセルフ登録、リード変換（Apexでのリード変換を有効にしていない場合）、削除の取り消し、Lightning SyncやEinstein Activity Captureによる追加、手動でのマージ、セルフサービスユーザーの作成では動きません。これらの経路も守りたい場合は、フローで別途チェックします。

フローで重複チェックが要る場面

重複ルールの対象外のオブジェクトを守りたいときや、「保存前に必ずこの条件を通す」という独自ロジックを組みたいときは、レコードトリガーフローで作ります。ここでは取引先名の完全一致チェックを例にします。

この処理は、トリガーになったレコードの項目を保存前に検証するだけなので、保存の前（before-save）のフローで組めます。保存の前フローは、データベースへの保存の直前に実行され、$Recordの値をそのまま検証に使えます。追加の保存処理が発生しない分、保存後（after-save）のフローより高速に動きます。

レコードトリガーフローを新規作成する
Flow Builderで「新規フロー」を選び、「レコードトリガーフロー」を選択します。
開始を設定する
オブジェクトに「取引先」を選び、トリガーは「レコードが作成された時」にします。「フローを最適化」は、保存の前に動く「高速項目更新」を選びます。
レコードを取得要素を追加する
表示ラベル「同名取引先の検索」、オブジェクトは「取引先」。条件は「取引先名」が「次の文字列と一致する」「{!$Record.Name}」、AND条件で「Id」が「次の文字列と一致しない」「{!$Record.Id}」を加えます。保存するレコード数は「条件に合致するすべてのレコード」にします。
決定要素を追加する
表示ラベル「重複有無チェック」。アウトカム「重複あり」の条件要件は「同名取引先の検索が空白ではない」にします。
カスタムエラー要素を追加する
「重複あり」のパスにつなげます。エラーメッセージに「同じ取引先名がすでに登録されています。既存のレコードをご確認ください。」と入力します。表示位置は画面上部のバナーでも、取引先名フィールドへのインライン表示でも選べます。
フローを保存して有効化する
フロー名とAPI参照名を入力し、保存後に「有効化」します。

カスタムエラー要素は、レコードトリガーフローの保存前・保存後どちらのパスでも使えます。エラーが発生すると、そのトリガーによる変更全体がロールバックされ、ユーザーは保存をやり直すまでレコードを確定できません。

「レコードを取得」要素が内部で行っている判定は、SOQLに書き換えると次のようなクエリに近い形です。

SELECT Id, Name
FROM Account
WHERE Name = :accountName
  AND Id != :currentRecordId

参考として示すクエリです。フロー上では要素の設定として組み立てます。

ここで間違えやすい

間違い	何が起きるか
ループの中に「レコードを取得」や「レコードを作成」を置く	対象件数ぶんSOQL・DMLが個別に発行され、ガバナ制限に達しやすくなります。要素はループの外に置きます
エントリ条件を絞らずに「作成または更新時」で動かす	更新のたびに同じチェックが走り、無関係な更新でもフローが実行されます
重複ルールで足りる範囲までフローで組んでしまう	標準機能で解決できる警告・ブロックを、保守対象の増えるフローに置き換えることになります
カスタムエラーのメッセージを255字を超えて書く	保存できません。文言は短く要点だけにします

動作確認のしかた

有効化したフローは、次の2パターンで確認します。

既存の取引先名と同じ名前で新規作成する。「レコードを取得」で1件以上ヒットし、「重複あり」の決定パスからカスタムエラーが表示され、保存がロールバックされることを確認します

既存にない取引先名で新規作成する。「レコードを取得」の結果が空になり、カスタムエラーを通らずに保存が完了することを確認します

エラーメッセージは、レコードページ上部のバナー表示と、対象フィールドへのインライン表示のどちらを選んでいるかで見え方が変わります。設定した表示位置と実際の見え方が一致しているかもあわせて確認します。

確認した環境

2026年9月／ Salesforce Summer '26（APIバージョン67.0）時点の公式ドキュメントで、重複ルールの仕様とレコードトリガーフローの要素構成を確認しています
ご自身の組織で作成・有効化する際は、サンドボックスでの確認をおすすめします

まとめ

取引先・取引先責任者・リード・個人取引先の重複防止は、まず標準の重複ルールと一致ルールを検討します
重複ルールにはクイック作成やExperience Cloudサイトのセルフ登録など、動かない保存経路があります
標準機能の対象外や独自条件が必要なときは、レコードトリガーフローの保存前パスで「レコードを取得」「決定」「カスタムエラー」を組み合わせます
「レコードを取得」「レコードを作成」はループの外に置き、ガバナ制限に達しないようにします
カスタムエラーが発生すると、そのトリガーによる変更はロールバックされます

参考：当時の画面

記事を最初に書いた当時の画面です。いまの手順と違うところは、各画像の説明に書いています。

新規フローの種類を選ぶダイアログ。画面フローとレコードトリガーフローが並ぶ — フローの種類を選ぶ画面です。当時は画面フローで作っていました。

Flow Builderの空のキャンバス。開始と終了だけが縦に並んでいる — 作り始めた直後のキャンバスです。開始と終了の間に要素を足していきます。

要素を追加のパネルが開き、画面やアクション、決定などが並んでいる — プラス印を押すと出る要素の一覧です。ここから必要な要素を選びます。

画面を編集の左ペインでテキストコンポーネントがピンク枠で強調されている — 画面要素にテキスト入力を置くところです。枠で囲んだ項目を選びます。

テキスト項目の設定。表示ラベルが取引先名、API参照名がAccountNameで必須にしている — 入力欄の表示ラベルとAPI参照名です。必須のチェックも忘れずに入れます。

画面要素が入ったキャンバス。開始、取引先名入力、終了の順に並ぶ — 画面要素が入った状態です。ここまでで入力を受け取る準備ができました。

要素を追加のパネルでデータの分類が表示され、レコードを取得が見えている — 次に足すのはデータの要素です。一覧を下へ送るとレコードを取得が出ます。

レコードを取得の設定。取引先を対象にIsDeletedがFalseの条件を入れている — 取得する対象と絞り込み条件です。保存するレコード数の選び方に注意します。

レコードトリガーフローでの同じレコードを取得の設定画面 — レコードトリガーフローで組んだ場合の同じ設定です。項目の並びは同じです。

フローを保存ダイアログ。表示ラベルとAPI参照名を入力している — フローの表示ラベルとAPI参照名を決めるところです。後から変えにくい項目です。

要素を追加のパネルでロジックの分類が表示され、決定やループが並ぶ — 取得のあとは判定です。ロジックの分類から決定を選びます。

新規決定の設定。対象取引先レコード有無チェックという名前で条件を入れている — 取得結果が空かどうかを判定する決定です。リソースと演算子の組み合わせを見てください。

新規決定のデフォルトの結果。条件不要と表示されている — もう一方の分岐はデフォルトの結果です。条件を書かなくても通ります。

新規決定の設定画面を拡大したもの。結果の表示ラベルと条件が読みやすい — 同じ画面を大きくしたものです。結果のAPI参照名まで確認できます。

決定の分岐が入ったキャンバス。有りと無しの2本のパスに分かれている — 決定を入れると分岐ができます。片方ずつ後続の要素をつないでいきます。

レコードを作成の設定。取引先のNameにAccountNameを入れている — 重複がないときにレコードを作る設定です。項目と値の対応を見てください。

新規リソースで変数DuplicatonCountを数値型として作る画面 — 重複件数を数える変数です。データ型と小数点の位置を指定します。

新規リソースで定数Zeroを数値型、値0として作る画面 — 初期化に使う定数です。値を0にしておきます。

新規割り当ての設定。DuplicatonCountにZeroを入れて初期化している — 数える前に変数を0へ戻す割り当てです。初期化を忘れると件数がずれます。

割り当て要素が入ったキャンバス。有りのパスに初期化が置かれている — 初期化を置いた位置です。分岐のどちら側に入れるかが要点です。

要素を追加のパネルでループが選ばれかけている状態のキャンバス — 取得した一覧を1件ずつ見るため、次にループを足します。

ループ要素の分岐。項目ごとと最後の項目の後の2本が出ている — ループには項目ごとと最後の項目の後の2本のパスができます。

新規決定の設定。取引先名が既に存在チェックという名前で文字列を突き合わせている — ループの中で1件ずつ名前を突き合わせる決定です。値の側がループの現在の項目です。

ループの中に決定が入ったキャンバス。既に存在するかしないかで分かれている — ループの中の分岐です。存在する側にだけ数える処理をつなぎます。

新規割り当ての設定。DuplicatonCountに1を追加している — 同じ名前が見つかったときに1を足す割り当てです。演算子が追加になっています。

要素を追加のパネルが開いたキャンバス。ループを抜けた先につなごうとしている — ループを抜けた後に、数えた結果を見る要素を足していきます。

新規決定の設定。DuplicatonCountが1以上かどうかを判定している — 数え終わった件数の判定です。1以上なら重複ありという分け方です。

件数判定の分岐。1以上と1未満の2本のパスが出ている — 判定の分岐です。1未満の側にだけレコード作成をつなぎます。

フロー全体の図。入力、取得、判定、ループ、レコード作成までが1枚に収まっている — 組み上がったフローの全体像です。要素の数と分岐の多さを見てください。

フローから作ったアクションの詳細画面。アクション種別がフローになっている — フローをボタンとして呼び出すためのアクションです。作成者名は伏せています。

取引先のレコードページ上部。作成したボタンがページのヘッダーに並んでいる — ページレイアウトへ足した直後です。ヘッダーにボタンが出ていれば配置できています。

取引先のリストビュー。1山田商会と1鈴木商会などが並んでいる — 試す前のリストです。この状態を基準に、後で件数が増えたかを見ます。

取引先のレコードページ。ヘッダーの重複防止ボタンがピンク枠で強調されている — 枠で囲んだボタンから確認を始めます。押すとフローの画面が開きます。

フローの画面で既存と同じ取引先名を入れ、赤枠のエラーが出ている — 既にある名前を入れたときです。赤枠と下のメッセージで止まります。

取引先のリストビュー。エラー後も件数が増えていない — エラーで止まった後のリストです。レコードが増えていないことを確認します。

取引先のリストビュー。同じ3件のまま変わっていない — 同じリストをもう一度開いたところです。やはり増えていません。

取引先のレコードページ。重複防止ボタンがピンク枠で強調されている — 今度は重複しない名前で試します。同じボタンから始めます。

フローの画面で2山田商会と入力し、エラーが出ていない状態 — 既にない名前を入れたときです。赤枠が出ずに次へ進めます。

取引先のリストビュー。2山田商会が追加されて4件になっている — 実行後のリストです。新しい行が増えていれば期待どおりの動きです。

取引先名の重複作成を止める重複ルールとフローの使い分け

なぜ重複作成を止めたいのか

標準の重複ルールでできること

フローで重複チェックが要る場面

レコードトリガーフローを新規作成する

開始を設定する

レコードを取得要素を追加する

決定要素を追加する

カスタムエラー要素を追加する

フローを保存して有効化する

ここで間違えやすい

動作確認のしかた

確認した環境

まとめ

参考：当時の画面

Salesforceの導入・運用についてご相談ください