商談更新時に旧新の取引先責任者の商談数を合わせ直す手順
商談の取引先責任者を変更すると、旧側の件数が残ったまま新側は増えません。付け替えを検知して両方を数え直すフローの作り方をまとめます。
なぜフローで集計するのか
標準の積み上げ集計項目は、マスタ詳細関係の主側にしか作成できません。参照関係の子には使えず、主側に積み上げ集計項目がある間は、マスタ詳細関係を参照関係へ変換することもできません。商談から取引先責任者への参照が参照関係(ルックアップ)になっている組織では、積み上げ集計項目という選択肢自体がありません。商談の更新で取引先責任者が付け替わったときも、フローで数え直します。
用意する2つの項目
商談(参照関係項目)と取引先責任者(数値項目)、2つの項目を使います。作成時・削除時の記事と共通の項目なので、すでに用意済みならこの節は飛ばせます。
| オブジェクト | 項目名 | 種別 | 役割 |
|---|---|---|---|
| 商談 | 取引先責任者 | 参照関係(取引先責任者) | どの取引先責任者にひもづく商談かを示す |
| 取引先責任者 | 商談数 | 数値(小数点0桁) | ひもづく商談の件数を格納する |
項目が無ければ商談側に作る
オブジェクトマネージャで商談を開き、参照関係項目として取引先責任者を追加します。
項目が無ければ取引先責任者側に作る
取引先責任者を開き、商談数を格納する数値項目を追加します。小数点の桁数は0で足ります。
フローを新規作成する
レコードトリガーフローを選ぶ
設定のFlowsから新規フローを作成し、「レコードトリガーフロー」を選びます。
開始対象を商談にする
オブジェクトで商談を選び、フローをトリガーする条件は「レコードが更新された場合」にします。
開始条件を参照項目の変更だけに絞る
条件の要件で「レコードが指定の条件を満たすように更新された場合のみフローを開始」を選び、取引先責任者項目に「値が変更された」条件を追加します。
開始条件を絞らずに全更新でフローを動かすこともできますが、取引先責任者が変わっていない更新のたびに無駄な再集計が走ります。参照項目が変わったときだけ動くようにするのが、更新トリガー特有の勘所です。
更新前後の取引先責任者を両方取得する
更新トリガーフローには、更新前の値を保持するグローバル変数が用意されています。$Record__Priorが更新前の値、$Recordが更新後の値です。商談が新規作成されたときは$Record__Priorの各項目がすべて空になるため、この変数は更新トリガーでのみ使います。
$Record__Prior.Contact__cと$Record.Contact__cを、決定要素で比較します。
| 比較結果 | 意味 |
|---|---|
| 一致する | 取引先責任者は変わっていない。他の項目だけが更新された |
| 一致しない | 取引先責任者が付け替わった |
取引先責任者が同じ場合
開始条件を取引先責任者が変わった更新だけに絞っているので、通常この分岐には入りません。開始条件を絞らずに動かす場合は、作成時の記事と同じ流れです。$Record.Contact__cにひもづく商談を取得要素で数え直し、その取引先責任者の商談数を更新します。
取引先責任者が変わった場合
一致しない場合は、旧取引先責任者と新取引先責任者の両方を更新します。ここが更新トリガー特有のつまずき所です。片方だけ更新すると、旧側の件数が減らないまま残ります。
旧取引先責任者を数え直す
取得要素で、Contact__cが$Record__Prior.Contact__cに一致する商談を集めます。更新後のデータベースにはすでに新しい参照先が反映されているため、この時点の商談はもう対象の商談自身を含みません。集めた件数をそのまま旧取引先責任者の商談数へ代入します。
新取引先責任者を数え直す
同じく取得要素で、Contact__cが$Record.Contact__cに一致する商談を集めます。更新後の商談はすでにこちらに含まれているので、集めた件数をそのまま新取引先責任者の商談数へ代入します。
2件のレコードを更新する
旧取引先責任者と新取引先責任者、それぞれのレコード変数をレコードを更新要素で保存します。
削除トリガーのように1を引く調整は要りません。更新トリガーフローが動く時点で、商談の参照先はすでに新しい値に変わっているためです。
一括更新時に気をつけること
商談の取引先責任者を、データローダーなどでまとめて付け替えることがあります。取引先責任者が変わったケースでは、1件の商談につき最大2レコード(旧・新の取引先責任者)を更新するため、作成時や削除時より重複更新の上限に達しやすくなります。1つのバッチで許可される重複更新の合計数は12件です。同じ取引先責任者が旧親・新親のどちらかとして13件以上関わる一括更新では、この上限に注意してください。
動作確認
更新前の商談数を確認する
付け替え前の旧取引先責任者と新取引先責任者、両方の商談数を控えておきます。
商談の取引先責任者を変更する
対象の商談を開き、取引先責任者を別のレコードへ変更して保存します。
両方の商談数を確認する
旧取引先責任者は1件減り、新取引先責任者は1件増えていれば成功です。
ここで間違えやすい
| 間違い | 何が起きるか |
|---|---|
| 開始条件を絞らない | 取引先責任者が変わっていない更新でも毎回再集計が走ります |
| 新取引先責任者だけ更新する | 旧取引先責任者の商談数が減らないまま残ります |
| 削除時と同じく1を引いてしまう | 更新後はすでに新しい参照先が反映されているため、1件多く引きすぎます |
| 一度に13件以上の商談で取引先責任者を付け替える | 重複更新の上限に当たり、更新が失敗することがあります |
確認した環境
- 2026年9月 / Salesforce Summer '26(APIバージョン67.0)時点の公式ヘルプで、$Record__Priorの仕様とフローの上限を確認しています
- 項目名は、ご自身の組織のものに置き換えてください
まとめ
- 取引先責任者が変わっていない更新まで拾わないよう、開始条件を参照項目の変更だけに絞ります
- $Record__Priorで更新前の取引先責任者、$Recordで更新後の取引先責任者を取得します
- 取引先責任者が変わった場合は、旧・新の両方を数え直して更新します。片方だけでは値が合いません
- 更新トリガーでは削除時のような1件分の調整は不要です。データベースにはすでに新しい参照先が反映されています
- 1件の更新で最大2レコードを更新するため、一括更新では重複更新の上限(12件)により注意します
参考:当時の画面
記事を最初に書いた当時の画面です。いまの手順と違うところは、各画像の説明に書いています。
Salesforceの導入・運用についてご相談ください
導入前の検討から、お使いの環境の改修・運用、AIとの連携まで承ります。状況を伺ったうえで、進め方をご提案します。