Salesforce Flow の設計と検証

設計、構築、またはレビューするすべての Flow に対して、これらのチェックを適用します。

ステップ 1 — Flow が正しいツールであることを確認

Flow を設計する前に、より軽量な宣言型オプションで問題を解決できないことを確認します。

要件	最適なツール
副作用なしでフィールド値を計算する	数式フィールド
ユーザーメッセージ付きで不正なレコード保存を防ぐ	検証ルール
親レコードの子レコードを集計またはカウントする	ロールアップサマリフィールド
複雑な複数オブジェクトロジック、コールアウト、または高ボリューム	Apex (Queueable / Batch) — Flow ではない
その他すべて	Flow ✓

数式フィールドまたは検証ルールで置き換え可能な Flow を構築している場合は、要件がより複雑であることをユーザーに確認させます。

ステップ 2 — 正しい Flow タイプを選択

ユースケース	Flow タイプ	主な制約
保存される前に同じレコードのフィールドを更新する	Before-save Record-Triggered	メールの送信、コールアウト、関連レコードの変更はできない
関連レコードの作成/更新、メール、コールアウト	After-save Record-Triggered	コミット後に実行 — 再帰トラップを回避
ユーザーをマルチステップ UI プロセスにガイドする	Screen Flow	レコードイベントによって自動的にトリガーできない
別の Flow から呼び出される再利用可能なバックグラウンドロジック	Autolaunched (Subflow)	入出力変数がコントラクトを定義する
Apex の @InvocableMethod から呼び出されるロジック	Autolaunched (Invocable)	入出力変数を宣言する必要がある
時間ベースのバッチ処理	Scheduled Flow	バッチコンテキストで実行 — ガバナ制限を尊重
イベント (Platform Events / CDC) に応答する	Platform Event–Triggered	非同期で実行 — 結果整合性

決定ルール: トリガーレコード自身のフィールドのみを変更する必要がある場合は before-save を選択します。関連レコードを触る必要がある場合、メールを送信する場合、またはコールアウトを行う場合は after-save に移動します。

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

これらのパターンはスケーリング時のガバナ制限の失敗です。Flow が有効化される前にすべてを確認します。

ループ内の DML — 自動的に失敗

Loop element
  └── Create Records / Update Records / Delete Records  ← ❌ ループ内の DML

修正: ループ内でレコードを収集変数に集め、その後ループ 外部 で DML 要素を実行します。

ループ内の Get Records — 自動的に失敗

Loop element
  └── Get Records  ← ❌ ループ内の SOQL

修正: ループ 前に Get Records クエリを実行し、その後コレクション変数をループします。

正しい一括パターン

Get Records — 1 つのクエリですべてのレコードを収集
└── コレクション変数をループ
    └── Decision / Assignment (DML なし、Get Records なし)
└── ループの後: Create/Update/Delete Records — 1 つの DML 操作

Transform vs ループ

目的がコレクションの変形である場合 (例: あるオブジェクトから別のオブジェクトへのフィールド値のマッピング)、ループ + Assignment パターンの代わりに Transform 要素を使用します。Transform は設計上一括安全で、より読みやすい Flow グラフを生成します。

ステップ 4 — 障害パス要件

実行時に失敗する可能性があるすべての要素には、障害コネクタが必要です。障害パスのない Flow はシステムエラーをユーザーに露出させます。

障害コネクタが必要な要素

• Create Records
• Update Records
• Delete Records
• Get Records (存在しない可能性がある必須レコードにアクセスする場合)
• Send Email
• HTTP Callout / External Service アクション
• Apex アクション (invocable)
• Subflow (サブフローが障害をスローできる場合)

障害ハンドラーパターン

Fault connector → Log Error (ロギングオブジェクトにレコードを作成するか Platform Event を発火)
               → ユーザーフレンドリーなメッセージを含むスクリーン要素 (Screen Flows)
               → Stop / End 要素 (Record-Triggered Flows)

障害パスを障害をスローした同じ要素に接続しないでください — これは無限ループを生成します。

ステップ 5 — 自動化密度チェック

デプロイ前に、同じオブジェクトとトリガーイベントに重複した自動化がないことを確認します。

• 同じ Object + When to Run の組み合わせ上のその他のアクティブな Record-Triggered Flows
• 同じオブジェクト上でまだアクティブなレガシー Process Builder ルール
• 同じフィールド変更でトリガーされる Workflow Rules
• 同じ before insert / after update コンテキストでも実行される Apex トリガー

重複した自動化は予期しない順序付け、再帰、ガバナ制限の失敗を引き起こす可能性があります。有効化前にオブジェクトの自動化インベントリを文書化します。

ステップ 6 — Screen Flow UX ガイドライン

• Screen Flow を通るすべてのパスは End 要素に到達する必要があります — 孤立したブランチはありません。
• マルチステップフローに対して Back ナビゲーションオプションを提供します。ただし、戻るナビゲーションがデータを破損させる場合は除きます。
• すべてのユーザー入力に対して lightning-input および SLDS 準拠コンポーネントを使用します — HTML フォーム要素は使用しないでください。
• ユーザーが進む前に必須入力の検証をスクリーン上で実行します — スクリーン上の Flow 検証ルールを使用します。
• Flow がセッション間でユーザーアクションを待つ必要がある場合、Pause 要素を処理します。

ステップ 7 — デプロイメント安全性

ドラフトとしてデプロイ    →   1 レコードでテスト   →   200+ レコードでテスト   →   有効化

• 有効化前に常に ドラフト としてデプロイし、徹底的にテストします。
• Record-Triggered Flows の場合: 正確なエントリ条件でテストします (例: ISCHANGED(Status) — テストデータが実際に条件をトリガーすることを確認)。
• Scheduled Flows の場合: 本番環境での有効化前にサンドボックスで小さいバッチでテストします。
• オブジェクトの Automation Density スコアをチェックします — 単一オブジェクト上の 3 つを超える有効な自動化は実行順序のリスクを増加させます。

クイックリファレンス — Flow アンチパターンサマリー

アンチパターン	リスク	修正
ループ内の DML 要素	ガバナ制限例外	DML をループの外に移動
ループ内の Get Records	SOQL ガバナ制限例外	ループ前にクエリを実行
DML/メール/コールアウト要素に障害コネクタなし	処理されない例外がユーザーに露出	そのような要素のすべてに障害パスを追加
再帰ガードのない after-save フローでトリガーレコードを更新	無限トリガーループ	エントリ条件または再帰ガード変数を追加
$Record コレクション上での直接ループ	スケーリング時の不正な動作	最初にコレクション変数に割り当て、その後ループ
新しい Flow と並行してアクティブな Process Builder	二重実行、予期しない順序付け	Flow を有効化する前に Process Builder を非有効化
すべてのブランチに End 要素のない Screen Flow	実行時エラーまたはスタックユーザー	すべてのブランチが End 要素に解決されることを確認