設定・自動化

商談更新時に旧新の取引先責任者の商談数を合わせ直す手順

商談の取引先責任者を変更すると、旧側の件数が残ったまま新側は増えません。付け替えを検知して両方を数え直すフローの作り方をまとめます。

2024.08.30

なぜフローで集計するのか

標準の積み上げ集計項目は、マスタ詳細関係の主側にしか作成できません。参照関係の子には使えず、主側に積み上げ集計項目がある間は、マスタ詳細関係を参照関係へ変換することもできません。商談から取引先責任者への参照が参照関係(ルックアップ)になっている組織では、積み上げ集計項目という選択肢自体がありません。商談の更新で取引先責任者が付け替わったときも、フローで数え直します。

用意する2つの項目

商談(参照関係項目)と取引先責任者(数値項目)、2つの項目を使います。作成時・削除時の記事と共通の項目なので、すでに用意済みならこの節は飛ばせます。

オブジェクト項目名種別役割
商談取引先責任者参照関係(取引先責任者)どの取引先責任者にひもづく商談かを示す
取引先責任者商談数数値(小数点0桁)ひもづく商談の件数を格納する
  1. 項目が無ければ商談側に作る

    オブジェクトマネージャで商談を開き、参照関係項目として取引先責任者を追加します。

  2. 項目が無ければ取引先責任者側に作る

    取引先責任者を開き、商談数を格納する数値項目を追加します。小数点の桁数は0で足ります。

商談のカスタム項目「取引先責任者」の定義画面。データ型は参照関係
商談側に作る参照関係項目です。API参照名のContact__cをフローの条件で使います。
取引先責任者のカスタム項目「商談数」の定義画面。データ型は数値
取引先責任者側に作る数値項目です。小数点の桁数は0で足ります。

フローを新規作成する

  1. レコードトリガーフローを選ぶ

    設定のFlowsから新規フローを作成し、「レコードトリガーフロー」を選びます。

  2. 開始対象を商談にする

    オブジェクトで商談を選び、フローをトリガーする条件は「レコードが更新された場合」にします。

  3. 開始条件を参照項目の変更だけに絞る

    条件の要件で「レコードが指定の条件を満たすように更新された場合のみフローを開始」を選び、取引先責任者項目に「値が変更された」条件を追加します。

新規フローの作成方法を選ぶ画面。「最初から開始」が選ばれている
新規フローの入口です。赤枠の「最初から開始」を選んで次へ進みます。
フロー種別の選択画面。「レコードトリガーフロー」が選ばれている
種別の選択です。赤枠のレコードトリガーフローを選んで作成を押します。
フローを保存する画面。表示ラベルとAPI参照名を入力している
フローに名前を付けて保存します。更新時の再集計だと分かる名前にしておきます。

開始条件を絞らずに全更新でフローを動かすこともできますが、取引先責任者が変わっていない更新のたびに無駄な再集計が走ります。参照項目が変わったときだけ動くようにするのが、更新トリガー特有の勘所です。

更新前後の取引先責任者を両方取得する

更新トリガーフローには、更新前の値を保持するグローバル変数が用意されています。$Record__Priorが更新前の値、$Recordが更新後の値です。商談が新規作成されたときは$Record__Priorの各項目がすべて空になるため、この変数は更新トリガーでのみ使います。

$Record__Prior.Contact__cと$Record.Contact__cを、決定要素で比較します。

レコードを取得要素の設定画面。$Record__Priorの取引先責任者を1件取得している
更新前の取引先責任者を取ります。値に$Record__Priorを指定しているところです。
レコードを取得要素の設定画面。$Recordの取引先責任者を1件取得している
更新後の取引先責任者を取ります。こちらの値は$Recordを指定します。
比較結果意味
一致する取引先責任者は変わっていない。他の項目だけが更新された
一致しない取引先責任者が付け替わった

取引先責任者が同じ場合

開始条件を取引先責任者が変わった更新だけに絞っているので、通常この分岐には入りません。開始条件を絞らずに動かす場合は、作成時の記事と同じ流れです。$Record.Contact__cにひもづく商談を取得要素で数え直し、その取引先責任者の商談数を更新します。

取引先責任者が変わった場合

一致しない場合は、旧取引先責任者と新取引先責任者の両方を更新します。ここが更新トリガー特有のつまずき所です。片方だけ更新すると、旧側の件数が減らないまま残ります。

  1. 旧取引先責任者を数え直す

    取得要素で、Contact__cが$Record__Prior.Contact__cに一致する商談を集めます。更新後のデータベースにはすでに新しい参照先が反映されているため、この時点の商談はもう対象の商談自身を含みません。集めた件数をそのまま旧取引先責任者の商談数へ代入します。

  2. 新取引先責任者を数え直す

    同じく取得要素で、Contact__cが$Record.Contact__cに一致する商談を集めます。更新後の商談はすでにこちらに含まれているので、集めた件数をそのまま新取引先責任者の商談数へ代入します。

  3. 2件のレコードを更新する

    旧取引先責任者と新取引先責任者、それぞれのレコード変数をレコードを更新要素で保存します。

レコードを取得要素の設定画面。Contact__cが更新前の取引先責任者と一致する商談を全件取得
旧取引先責任者にひもづく商談を数えます。保存はすべてのレコードを選びます。
レコードを取得要素の設定画面。Contact__cが更新後の取引先責任者と一致する商談を全件取得
新取引先責任者側も同じように数えます。条件の値だけ$Recordに変えます。
新規リソース画面。数値型の変数oppNumbersBeforeUpdateを作成している
旧側の件数を入れる変数です。デフォルト値は0にしておきます。
新規リソース画面。数値型の変数oppNumbersを作成している
新側の件数を入れる変数です。旧と新で変数を分けておくのが要点です。
割り当て要素の設定画面。oppNumbersBeforeUpdateに更新前の商談件数を代入している
旧側の件数を変数へ入れます。削除時のように1を引く調整は要りません。
割り当て要素の設定画面。oppNumbersに更新後の商談件数を代入している
新側も同じく、数えた件数をそのまま変数へ入れます。
レコードを更新要素の設定画面。更新前の取引先責任者のOppCounts__cを書き換えている
旧取引先責任者の更新です。Idの条件に$Record__Priorを使っています。
レコードを更新要素の設定画面。更新後の取引先責任者のOppCounts__cを書き換えている
新取引先責任者の更新です。こちらはIdの条件に$Recordを使います。

削除トリガーのように1を引く調整は要りません。更新トリガーフローが動く時点で、商談の参照先はすでに新しい値に変わっているためです。

一括更新時に気をつけること

商談の取引先責任者を、データローダーなどでまとめて付け替えることがあります。取引先責任者が変わったケースでは、1件の商談につき最大2レコード(旧・新の取引先責任者)を更新するため、作成時や削除時より重複更新の上限に達しやすくなります。1つのバッチで許可される重複更新の合計数は12件です。同じ取引先責任者が旧親・新親のどちらかとして13件以上関わる一括更新では、この上限に注意してください。

動作確認

  1. 更新前の商談数を確認する

    付け替え前の旧取引先責任者と新取引先責任者、両方の商談数を控えておきます。

  2. 商談の取引先責任者を変更する

    対象の商談を開き、取引先責任者を別のレコードへ変更して保存します。

  3. 両方の商談数を確認する

    旧取引先責任者は1件減り、新取引先責任者は1件増えていれば成功です。

商談テスト1の詳細画面。取引先責任者にContactBが入っている
付け替え前の商談です。取引先責任者がContactBであることを確かめます。
取引先責任者ContactBの詳細画面。商談数が2と表示されている
付け替え前の商談数です。赤枠の値を控えてから操作を始めます。
商談テスト11の詳細画面。取引先責任者にContactBが入っている
付け替える対象の商談です。この時点ではContactBにひもづいています。
取引先責任者ContactBの詳細画面。商談数が3と表示されている
商談が増えた直後の件数です。赤枠が3件になっているのが分かります。
商談テスト11の詳細画面。取引先責任者が別のレコードへ変わっている
取引先責任者を別のレコードへ変えたところです。ここでフローが動きます。
取引先責任者ContactBの詳細画面。商談数が2に戻っている
付け替え後の旧側の件数です。赤枠が3から2へ1件減っていれば成功です。

ここで間違えやすい

間違い何が起きるか
開始条件を絞らない取引先責任者が変わっていない更新でも毎回再集計が走ります
新取引先責任者だけ更新する旧取引先責任者の商談数が減らないまま残ります
削除時と同じく1を引いてしまう更新後はすでに新しい参照先が反映されているため、1件多く引きすぎます
一度に13件以上の商談で取引先責任者を付け替える重複更新の上限に当たり、更新が失敗することがあります

確認した環境

  • 2026年9月 / Salesforce Summer '26(APIバージョン67.0)時点の公式ヘルプで、$Record__Priorの仕様とフローの上限を確認しています
  • 項目名は、ご自身の組織のものに置き換えてください

まとめ

  • 取引先責任者が変わっていない更新まで拾わないよう、開始条件を参照項目の変更だけに絞ります
  • $Record__Priorで更新前の取引先責任者、$Recordで更新後の取引先責任者を取得します
  • 取引先責任者が変わった場合は、旧・新の両方を数え直して更新します。片方だけでは値が合いません
  • 更新トリガーでは削除時のような1件分の調整は不要です。データベースにはすでに新しい参照先が反映されています
  • 1件の更新で最大2レコードを更新するため、一括更新では重複更新の上限(12件)により注意します

参考:当時の画面

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

フローの開始を設定する画面。条件はレコードが更新された、エントリ条件はなし
エントリ条件が「なし」のままです。
フロー全体図。取得と割り当てと更新が旧新の順に一直線に並んでいる
当時は決定要素を置いていません。

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

導入前の検討から、お使いの環境の改修・運用、AIとの連携まで承ります。状況を伺ったうえで、進め方をご提案します。