【Salesforce】Salesforce Flowの分岐が想定と違う時のレポート条件と項目設定の直し方

Salesforce Flowの分岐ロジックが期待通りに動作しないケースは、業務プロセスに直接影響を与えるため迅速な原因特定が求められます。多くの場合、問題はフローが参照するレコードの項目値やトリガ条件の設定ミスに起因します。本記事では、レポート条件を活用した切り分け方法と、項目設定の具体的な修正手順を実務視点で解説します。これにより、フロー開発者や管理者が自信を持って分岐を修正できるようになります。

なぜ分岐が想定と違うのか?よくある原因

分岐が想定通りに動作しない原因は、大きく三つに分類されます。それぞれを理解することで、修正の優先順位を付けやすくなります。

レコードトリガ条件の誤り

フローが起動する条件そのものが間違っているケースです。例えば、「レコードが作成されたとき」にトリガする設定だが、既存レコードの更新でも動作させたい場合、条件式でフィルタリングする必要があります。また、トリガ条件に使用する項目にインデックスがないと、大量レコード時に動作が不安定になることもあります。

フロー内の条件式と項目値の不一致

フローの分岐に設定した条件式が、実際のレコードの項目値と合っていない場合です。数式項目は保存時に評価されるタイミングが異なるため、予期せぬ結果を生むことがあります。また、ピックリストの表示ラベルとAPI名の混同や、参照項目のNULLチェック漏れも頻出パターンです。

フローのバージョン管理の問題

過去のバージョンが有効になっており、最新の修正が反映されていないケースです。また、複数のフローが同じオブジェクトに対してトリガ設定されている場合、実行順序や重複の影響で意図しない分岐が発生することもあります。

レポート条件を使って原因を切り分ける

問題の切り分けには、レポートでフローが処理したはずのレコードを抽出し、条件を満たすかどうかを確認する方法が効果的です。以下の手順で進めます。

1. フローのトリガ条件を確認する(例:Statusが’In Progress’のレコードが更新されたとき)。
2. その条件に一致するレコードをレポートに作成する。例えば「Status = In Progress」のフィルタを設定します。
3. フローが実行された時刻を確認し、該当レコードが想定通り抽出されているか確認します。
4. フローの分岐条件をレポートのフィルタに追加し、実際の値が条件を満たしているか検証します。
5. レポートで抽出されたレコードと、フローのデバッグログを照合し、乖離がある場合は原因箇所を特定します。

下表は、正常時と異常時のレポート結果の比較例です。実際にレポートを確認する際の参考にしてください。

確認項目	正常時	異常パターンA	異常パターンB
トリガ条件レコード数	10件	10件(正しい)	0件(トリガされていない)
フロー実行ログ数	10件	5件(一部未実行)	0件
分岐A通過レコード数	6件	5件(条件過剰)	N/A
分岐B通過レコード数	4件	0件(条件未達)	N/A

上記のように、レポートでフィルタを適用しながら実データを確認することで、トリガ条件と分岐条件のどちらに問題があるかを明確にできます。

項目設定の見直しと直し方

分岐に使用する項目の設定を確認し、適切に修正する具体的な手順を解説します。

条件式で使う項目のデータ型と値の確認

まず、条件式で参照する各項目のデータ型をSalesforceのオブジェクト定義で確認します。数値・日付・テキストなど型が一致していないと、比較が正しく行われません。また、数式項目は保存時の値が利用されるため、フロー実行時に期待する値と異なる場合があります。その際は、数式をワークフロー更新などで即座に評価するよう変更するか、フロー内で数式項目を再度計算する必要があります。

ピックリスト値のAPI名と表示ラベルの一致確認

ピックリスト項目を条件に使う場合、フローではAPI名で比較するのが基本です。表示ラベルで比較するには「表示ラベルを取得」などの関数を使いますが、意図しない結果になりがちです。実際のレコードの値(API名)をレポートでリスト表示し、フロー条件と合致しているか確認しましょう。

参照関係の項目のnullチェックとドット表記

参照項目(ルックアップやマスター詳細)を条件に使う場合、参照先が空のレコードでエラーにならないよう、必ずNULLチェックを条件式の先頭に配置します。また、ドット表記で参照先の項目を指定する際、スペルや参照の深さに注意が必要です。例えば「Account.Industry」と書くべきところを「Account_Industry」と書くと、条件式はエラーにはなりませんが常にNULLとなり想定外の分岐になります。

1. フローエディタで該当の分岐要素を開き、条件式を書き留めます。
2. レポートを実行し、条件式で使われている全項目の値をレコードごとに確認します。
3. 条件式の値とレポートの値が完全に一致しているか検証します。大文字小文字や空白の違いにも注意します。
4. 不一致がある場合、項目設定を変更するか、条件式を修正します。変更後はテスト実行で動作を確認します。
5. 複数の条件がAND/ORで結合されている場合、括弧の位置が正しいか論理演算子の優先順位に注意して見直します。
6. 最後に、フローのデバッグログを再度取得し、目的の分岐を通過していることを確認します。

失敗パターンとその対処法

実際の現場でよく遭遇する失敗パターンと、その具体的な対処法をまとめます。

パターン1: 日付比較で想定外の分岐 – 日付項目と日付/時間項目の比較では、時刻部分が影響します。DATEVALUE関数を使って日付部分のみを比較する、または時間を0に揃えるなどの調整が必要です。

パターン2: OR条件の誤ったグループ化 – 「AまたはBかつC」のような条件(A OR B AND C)は実際には「A OR (B AND C)」と解釈されるため、意図が異なる場合があります。明示的に括弧を追加してグループ化します。

パターン3: 数式項目の再計算タイミング – 数式項目はレコード保存時に再計算されます。フロー内で項目を更新した直後に数式項目を条件に使うと、古い値を参照することがあります。その場合は、ワークフロー更新やプロセスビルダーで即時評価させるか、フロー内で値を変数に代入してから比較します。

パターン4: 参照項目の間接NULL伝播 – 参照先オブジェクトが存在しないレコードで、ドット表記を使って「Account.Industry」と参照するとNULLになります。NULLチェックをしていないと、条件式が常に「False」になり分岐を通過しません。必ずISNULL関数で事前チェックを行います。

管理者に伝えるべき情報と確認依頼

トラブルシューティングでは、管理者が以下の情報を収集できると原因特定がスムーズになります。

• Debug Logs(デバッグログ): フローの実行をトレースするために、管理者に該当ユーザーのデバッグログを有効にしてもらい、フロー実行前後のログを取得します。ログには評価された条件式とその結果が出力されます。
• Flow Historyレポート: フローの実行履歴をレポートで確認できる「Flow History」を有効にしておくと、どのレコードでどの分岐を通過したかが一目でわかります。管理者にこの機能の有効化を依頼してください。
• フロー定義のエクスポート: フローが複雑な場合はXMLでエクスポートして差分を比較することで、誤った条件を見つけやすくなります。

よくある質問(FAQ)

Q: フローを再実行する方法はありますか?

A: フローに「再実行ボタン」は標準ではありませんが、対象レコードの項目を更新してトリガ条件を満たすようにするか、フローを「一時停止→再有効化」することで強制的に再実行させることができます。ただし、大量のレコードを対象にする場合は注意が必要です。

Q: 条件を変更したのに反映されないのはなぜですか?

A: フローのバージョンが「有効」になっているか確認してください。また、キャッシュの影響で古いバージョンが残っている場合があるため、数分待ってから再テストするか、ブラウザのキャッシュをクリアしてください。

Q: 大量のレコードで分岐が遅い場合の対処法は?

A: トリガ条件にインデックスが付いた項目を使う、フロー内でループを避ける、条件式をシンプルにするなどの工夫が効果的です。また、バッチ処理を検討するか、Platform Eventを利用した非同期処理に切り替える方法もあります。

まとめ

Salesforce Flowの分岐が想定通りに動作しない場合、まずはレポートを使ってトリガ条件と分岐条件の両方を実データで検証することが重要です。その上で、項目のデータ型やピックリスト値のAPI名、参照項目のNULLチェックなど、細かな設定ミスを見直します。本記事で紹介した切り分け手順と修正方法を実践することで、多くの原因を特定・解決できるはずです。フローの設計時からテスト実行とログ確認の習慣を身につけ、安定した自動化を実現してください。