取引先の活動作成時に取引先責任者を自動でひもづけるフロー

名前（WhoId）と関連先（WhatId）は役割が違う

活動（ToDo・行動）には、人物を指す「名前（WhoId）」と、業務レコードを指す「関連先（WhatId）」という2つの参照項目があります。どちらも指せる相手が1種類に固定されていないポリモーフィック（多態）な参照項目ですが、指せる相手の顔ぶれがまったく違います。

⚠️ 取引先責任者を入れたいのは名前（WhoId）のほうです。関連先（WhatId）に取引先責任者のIdを入れることはできません。この役割分担は、人物か業務レコードかで分かれていると覚えます。

対象はToDo（Task）で作り、行動（Event）へ複製する

活動はToDo（Task）と行動（Event）の2つに分かれています。名前・関連先・取引先の3項目は、どちらのオブジェクトでも同じ構造です。そのため、片方で作った手順をそのままもう片方へ写せます。

この記事ではToDoを例にします。取引先の詳細画面の「活動」関連リストから作る記録は、電話・メール・訪問メモといったToDoのほうが件数が多く、自動化の効き目が大きいためです。行動にも同じ仕組みが要る場合は、同じ内容のフローをもう1本、行動を対象に作ります。1本のレコードトリガーフローが2つのオブジェクトを同時に受け持つことはできません。

保存前（高速項目更新）で組む

このフローが書き換えるのは、トリガーになった活動自身の名前（WhoId）だけです。関連レコードへは何も書き込みません。この形は、保存前に走るレコードトリガーフローがちょうど受け持つ範囲に収まります。

公式ヘルプは、保存前のレコードトリガーフローについて「サポートされる要素は、割り当て・決定・レコードを取得・ループだけ」と明記しています。取引先と取引先責任者を引くための「レコードを取得」も、WhoIdへ値を入れるための「割り当て」も、この4つの中に入っています。

⚠️ 開始の設定で「フローを最適化」の選択肢に「高速項目更新」が出ることを、先に確認してください。ここに「アクションと関連レコード」しか出ない場合は、保存前では組めません。その場合は、後半の「保存前が選べない場合は保存後で組む」の組み方に切り替えます。

手がかりは取引先ID（AccountId）ではなく関連先ID（WhatId）

活動には「取引先（AccountId）」という項目もあり、一見こちらのほうが素直に見えます。ですが、保存前フローではこの項目を使えません。

• AccountIdは読み取り専用で、値が入るのは保存の処理が走ったあとです。保存前フローが動く時点では、まだ空です
• AccountIdは関連先が取引先のときだけ入るわけではありません。関連先が商談やケースなら、その商談・ケースがぶらさがっている取引先のIdが入ります。「関連先に取引先を指定したとき」という条件とはずれます

そのため、手がかりには$Record.WhatIdを使います。関連先が商談やケースを指している活動は、取引先の検索で1件も取れないので、そこで自然に対象から外れます。IdのプレフィックスをIF文で見分けるような細工は要りません。

フローを作成する

1. 開始のオブジェクトとタイミングを決める

   対象のオブジェクトは「ToDo」、トリガーは「レコードが作成された」にします。「フローを最適化」では「高速項目更新」を選びます。これが保存前で動かす指定です。

2. 入り口条件で対象を絞る

   エントリ条件に「関連先IDがnullでない」と「名前IDがnullである」の2つを入れ、すべての条件に一致する設定にします。関連先が空の活動と、名前を手入力済みの活動を、フローが動く前に外しておきます。

3. 関連先の取引先を取得する

   レコードを取得要素で、オブジェクトは「取引先」、条件は「Id」が「{!$Record.WhatId}」に一致。保存するレコード数は「最初のレコードのみ」にします。関連先が取引先以外を指している活動は、ここで何も取得できません。

4. 取引先責任者を取得する

   もう一度レコードを取得要素を使い、オブジェクトは「取引先責任者」、条件は「取引先ID」が、ひとつ前で取得した取引先の「Id」に一致。並び替え項目を「作成日」、並び替え順を「昇順」に指定したうえで「最初のレコードのみ」にします。

5. 両方とも取得できたかを判定する

   決定要素を1つ置き、取得した取引先責任者が「null でない」ことを条件にします。取引先が取れなければ取引先責任者も取れないので、判定は取引先責任者の1本で足ります。

6. 名前へ取引先責任者を入れる

   割り当て要素で、{!$Record.WhoId} に、取得した取引先責任者の Id を入れます。WhoIdは多態な参照項目なので、取引先責任者のレコード変数そのものではなく、その Id を入れます。

7. 保存して有効化する

   表示ラベルとAPI参照名を入力して保存し、有効化します。ToDoを対象にしたことが分かる名前にしておくと、あとで行動用のフローと取り違えません。

取得できない場合に備える

関連先が取引先以外を指している、または取引先に取引先責任者が1件もない場合、取得要素は空のまま次へ進みます。決定要素を通さずに割り当てへ直行させると、WhoIdへ空が入るだけで済むこともありますが、意図しない書き換えの温床になります。取得できたときだけ割り当てへ進む分岐を、必ず1つ置いてください。取得できなかった側のパスは、何もせずフローを終えます。

複数の取引先責任者がいる場合

同じ取引先に取引先責任者が何人もいることは珍しくありません。並び替えを指定しないと、実行のたびにどの取引先責任者が選ばれるか安定しません。

⚠️ 業務上「主担当」の考え方がある場合は、取引先責任者にチェックボックス項目を追加し、レコードを取得要素の条件にそのチェックボックスを加えます。どの取引先責任者が選ばれるかを業務ルールとして先に決めてから実装するのが、いちばん揉めません。

すでに名前が入っている活動を上書きしない

メール連携や外部ツールから作られる活動は、はじめから名前が入っていることがあります。エントリ条件に「名前IDがnullである」を入れておくと、手で入れた担当者や連携が入れた担当者を、フローが上書きしません。あとから「担当が勝手に変わる」という問い合わせを受けずに済みます。

保存前が選べない場合は保存後で組む

開始の設定で「高速項目更新」が出ない場合や、すでに保存後のフローで組んでしまっている場合は、次の2点を差し替えれば同じ結果になります。

1. 最適化を「アクションと関連レコード」にする

   保存後に動くフローになります。この時点で「レコードを更新」要素が使えるようになります。

2. 割り当て要素を「レコードを更新」要素に差し替える

   更新対象は「フローをトリガーした活動のレコード」。項目は「名前ID」、値は取得した取引先責任者の Id です。手がかりには保存前と同じく関連先ID（WhatId）を使えますが、保存後であれば取引先ID（AccountId）も使えます。

⚠️ 保存後で組むと、活動を保存したあとにもう一度更新が走ります。動きはしますが、保存の処理が2周するぶん遅くなり、他のフローやトリガーを再び動かします。選べるなら保存前のほうが素直です。

動作確認

1. 取引先を作成する

   活動をひもづける先の取引先を、確認用に1件作成します。

2. 取引先責任者を作成する

   作成した取引先の配下に、取引先責任者を2件作成します。1件だけだと、並び替えが効いているかを確かめられません。

3. 取引先の活動関連リストからToDoを作成する

   取引先の詳細画面にある「活動」からToDoを作成して保存します。この経路なら、関連先にその取引先が自動で入ります。

4. 名前を確認する

   保存直後のToDoで、名前に先に作ったほうの取引先責任者が入っていることを確認します。フローのデバッグ画面を使うと、各要素が何を取得したかもあわせて追えます。

5. 関連先が商談の場合も試す

   商談の活動関連リストからもToDoを作り、こちらでは名前が空のままであることを確認します。取引先の取得が空振りして、意図どおり対象から外れています。

ここで間違えやすい

確認した環境

• 2026年9月 ／ Salesforce Summer '26（APIバージョン67.0）時点の公式ヘルプで、保存前フローでサポートされる4つの要素と、保存後でなければ扱えない値（新規レコードのIdなど）を確認しています
• WhoId・WhatId・AccountIdが指せる相手と、AccountIdが読み取り専用であることは、私たちの検証組織へREST APIのdescribeを実行して確認しています。APIのバージョンも同じ組織で67.0が最新であることを確認しました

まとめ

• 名前（WhoId）が指せるのは取引先責任者とリードだけ、関連先（WhatId）が指せるのは取引先・商談などの業務レコードです
• 手がかりには関連先ID（WhatId）を使います。取引先ID（AccountId）は読み取り専用で、保存前フローの時点ではまだ空です
• 更新するのが活動自身の名前だけなら、保存前フローで完結します。使える要素は割り当て・決定・レコードを取得・ループの4つです
• 取引先責任者が複数いる場合の並び替えは、後から動かない「作成日の昇順」にします。最終更新日は編集のたびに結果が変わります
• エントリ条件に「名前IDがnull」を入れ、すでに担当者が入っている活動は上書きしません
• ToDoと行動は同じ構造ですが、フローは対象オブジェクトごとに1本ずつ作ります

参考：当時の画面

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