salesforce-flow-design

Salesforce Flow の設計と検証

設計、構築、レビューするすべての Flow に、次のチェックを適用してください。

ステップ 1 — Flow が適切なツールか確認する

Flow を設計する前に、より軽量な宣言型の方法で問題を解決できないか確認してください。

要件	最適なツール
副作用なしで項目値を計算する	数式項目
ユーザーメッセージを表示して不正なレコード保存を防ぐ	入力規則
親レコード上で子レコードを合計またはカウントする	積み上げ集計項目
複雑な複数オブジェクトのロジック、コールアウト、大量データ処理	Apex（Queueable / Batch）— Flow ではありません
その他すべて	Flow ✓

数式項目または入力規則で置き換えられる Flow を構築している場合、その要件が本当により複雑なのか、ユーザーに確認してください。

ステップ 2 — 適切な Flow の種類を選ぶ

ユースケース	Flow の種類	主な制約
保存前に同じレコードの項目を更新する	保存前レコードトリガー	メール送信、コールアウト、関連レコードの変更はできません
関連レコード、メール、コールアウトを作成または更新する	保存後レコードトリガー	コミット後に実行されます — 再帰の落とし穴を避けてください
複数ステップの UI プロセスをユーザーに案内する	画面 Flow	レコードイベントによって自動的にトリガーすることはできません
別の Flow から呼び出される再利用可能なバックグラウンドロジック	自動起動（サブフロー）	入出力変数で契約を定義します
Apex @InvocableMethod から呼び出されるロジック	自動起動（呼び出し可能）	入出力変数を宣言する必要があります
時間ベースのバッチ処理	スケジュール済み Flow	バッチコンテキストで実行されます — ガバナ制限を守ってください
イベントへの応答（Platform Events / CDC）	プラットフォームイベントトリガー	非同期で実行されます — 結果整合性となります

判断ルール：トリガーとなったレコード自身の項目だけを変更する場合は、保存前を選んでください。関連レコードの変更、メール送信、またはコールアウトが必要になった時点で、保存後に切り替えてください。

ステップ 3 — 一括処理の安全性チェックリスト

次のパターンは、大規模な処理でガバナ制限違反を引き起こします。Flow を有効化する前に、すべて確認してください。

ループ内の DML — 即時不合格

Loop element
  └── Create Records / Update Records / Delete Records  ← ❌ DML inside loop

修正方法：ループ内でレコードをコレクション変数に集めてから、DML 要素をループの外で実行します。

ループ内のレコード取得 — 即時不合格

Loop element
  └── Get Records  ← ❌ SOQL inside loop

修正方法：ループの前にレコード取得クエリを実行してから、コレクション変数をループ処理します。

適切な一括処理パターン

Get Records — collect all records in one query
└── Loop over the collection variable
    └── Decision / Assignment (no DML, no Get Records)
└── After the loop: Create/Update/Delete Records — one DML operation

Transform とループの使い分け

コレクションの形を変えることが目的の場合（例：あるオブジェクトから別のオブジェクトへ項目値をマッピングする場合）、ループ＋割り当てパターンではなく、Transform 要素を使用してください。Transform は設計上、一括処理に安全で、より見やすい Flow グラフを作成できます。

ステップ 4 — フォールトパスの要件

実行時に失敗する可能性があるすべての要素には、フォールトコネクタが必要です。フォールトパスのない Flow は、未加工のシステムエラーをユーザーに表示します。

フォールトコネクタが必要な要素

• レコードを作成
• レコードを更新
• レコードを削除
• レコードを取得（存在しない可能性がある必須レコードにアクセスする場合）
• メールを送信
• HTTP コールアウト／外部サービスアクション
• Apex アクション（呼び出し可能）
• サブフロー（サブフローがフォールトを発生させる可能性がある場合）

フォールトハンドラーパターン

Fault connector → Log Error (Create Records on a logging object or fire a Platform Event)
               → Screen element with user-friendly message (Screen Flows)
               → Stop / End element (Record-Triggered Flows)

フォールトパスを、フォールトが発生した同じ要素に決して接続しないでください。無限ループが発生します。

ステップ 5 — 自動化の密度を確認する

デプロイ前に、同じオブジェクトおよびトリガーイベントで重複する自動化がないことを確認してください。

• 同じ Object ＋ When to Run の組み合わせで有効になっている他のレコードトリガー Flow
• 同じオブジェクトで有効なレガシー Process Builder ルール
• 同じ項目の変更時に実行されるワークフロールール
• 同じ before insert ／ after update コンテキストで実行される Apex トリガー

自動化が重複すると、予期しない実行順序、再帰、ガバナ制限違反が発生する可能性があります。有効化する前に、そのオブジェクトの自動化一覧を文書化してください。

ステップ 6 — 画面フローの UX ガイドライン

• 画面フローのすべての経路が End 要素に到達するようにします。孤立した分岐を作らないでください。
• 複数ステップのフローでは、戻る操作によってデータが破損する場合を除き、Back ナビゲーションを用意します。
• すべてのユーザー入力には lightning-input と SLDS 準拠のコンポーネントを使用します。HTML フォーム要素は使用しないでください。
• ユーザーが次に進む前に、画面上で必須入力を検証します。画面上の Flow 検証ルールを使用してください。
• セッションをまたいでユーザーの操作を待つ必要がある場合は、Pause 要素を処理します。

ステップ 7 — デプロイの安全性

Deploy as Draft    →   Test with 1 record   →   Test with 200+ records   →   Activate

• まず必ず Draft としてデプロイし、有効化する前に十分にテストします。
• レコードトリガーフローの場合：正確なエントリー条件（例：ISCHANGED(Status)）を使ってテストします。テストデータが実際にその条件を満たすことを確認してください。
• スケジュール済みフローの場合：本番環境で有効にする前に、サンドボックスで少量のバッチを使ってテストします。
• オブジェクトの自動化密度スコアを確認します。1 つのオブジェクトで有効な自動化が 3 つを超えると、実行順序に関するリスクが高まります。

クイックリファレンス — フローのアンチパターンの概要

アンチパターン	リスク	対処法
ループ内の DML 要素	ガバナー制限の例外	DML をループの外に移動する
ループ内の Get Records	SOQL ガバナー制限の例外	ループの前にクエリを実行する
DML／メール／コールアウト要素にフォールトコネクタがない	未処理の例外がユーザーに表示される	そのような要素すべてにフォールトパスを追加する
再帰ガードなしで、保存後フロー内のトリガーレコードを更新する	無限のトリガーループ	エントリー条件または再帰ガード変数を追加する
$Record コレクションを直接ループする	大規模時に誤った動作が発生する	まずコレクション変数に割り当ててからループする
新しい Flow と並行して Process Builder が有効なままになっている	二重実行、予期しない実行順序	Flow を有効化する前に Process Builder を無効化する
すべての分岐に End 要素がない画面フロー	実行時エラーまたはユーザーが先に進めなくなる	すべての分岐が End 要素に到達するようにする