【Salesforce】サブフローの結果が異なる時の設定値と処理順の確認

Salesforceのフロー機能を使いこなす中で、サブフローを呼び出した際に期待とは異なる結果が返ってくる経験はありませんか。特に複数のフローが連携する場面では、処理の順序や変数の受け渡しに起因する問題が発生しやすくなります。本記事では、サブフローが想定通りに動作しない原因を特定するための具体的な確認手順と設定値を解説します。実際の業務で直面しやすいパターンを想定し、開発者や管理者が自ら切り分けられるよう、実践的な内容に絞っています。

サブフローの設定値が想定とズレる主な原因

サブフローが期待通りに動かない場合、多くの原因は設定値の誤りにあります。特に、入力変数と出力変数のマッピングが正しく行われていないケースが頻出します。例えば、サブフロー側で参照する項目が更新されずに古い値のまま渡される、あるいは出力変数の戻り値が呼び出し元で正しく受け取れていないといった症状が挙げられます。また、変数のデータ型が不一致であると、暗黙の型変換が行われずにエラーとなることもあります。

さらに、サブフロー内で使用するアクセスレベルも重要な要素です。サブフローが「システム権限なし」で実行される場合、参照・更新できるオブジェクトが制限されるため、想定外の動作を引き起こす可能性があります。特に、共有ルールやプロファイルの設定に依存する処理では、サブフローの「アクセスレベル」を「システム権限あり」に変更する必要があるかどうかを確認する必要があります。

加えて、サブフローを呼び出すタイミングによっては、呼び出し元のフローで使用する変数がサブフロー内で変更され、その影響が後続の処理に及ぶ場合もあります。参照渡しの動作を理解しておかないと、値が意図せず書き換えられる原因となります。

呼び出し元フローとサブフローの処理順を確認する方法

サブフローが正しいタイミングで実行されているかどうかを確認するには、Salesforceのフローデバッグログを利用するのが最も確実です。呼び出し元フローとサブフローは同一トランザクション内で動作するため、ログ出力のタイムスタンプがほぼ同一になります。しかし、ログの中では「FlowInterview」という要素ごとに処理順が記録されます。具体的には、サブフローの開始要素「Subflow Start」と終了要素「Subflow End」の間に、サブフロー内の各要素の実行が記録されます。

デバッグログの取得手順

1. 設定から「デバッグログ」を開き、新しいトレースフラグを作成します。対象のユーザまたはAPIユーザを指定し、開始日時と終了日時を設定します(通常は数時間程度)。
2. トレースフラグが有効な状態で、問題が発生するフローを手動またはスクリプトで実行します。
3. 「デバッグログ」一覧に生成されたログを開き、「検索」機能で該当フローのID(例:300…)を入力してフィルタリングします。
4. ログ内で「FLOW_*」のカテゴリを探し、要素の実行順と変数の値を確認します。特に、サブフロー呼び出し前後での変数値の変化に注目します。
5. サブフローが非同期で呼ばれている場合は、別のトランザクションで実行されるため、ログが分割されます。その場合は、サブフローのトランザクションIDを確認して個別に追跡する必要があります。

処理順に影響を与える要因

サブフローの処理順は、呼び出し元のフローの要素配置と、サブフローが同期か非同期待機かによって決まります。同期サブフローの場合、呼び出し元はサブフローの完了を待ってから次の要素に進みます。非同期待機の場合は、サブフローを開始した後、待機せずに次の処理を続行します。これにより、期待した値がサブフローから返される前に後続の処理が実行され、結果的に変数の値が古いまま使われることがあります。特に、非同期待機のサブフローで出力変数を使用する場合は、呼び出し元で適切な分岐や待機処理を実装する必要があります。

よくある失敗パターンとその対策

実務でよく遭遇する失敗パターンをいくつか紹介します。これらの知識があれば、デバッグの際に素早く原因を特定できるでしょう。

パターン1: 入力変数がNULLで渡される

呼び出し元で変数に値を設定したつもりでも、サブフロー側でNULLとして受け取られるケースがあります。原因としては、変数の割り当てがサブフロー呼び出しの後に行われている、または条件分岐で値の代入がスキップされている可能性があります。また、呼び出し元の変数が「空白(スペース)」である場合、Salesforceの動作上、NULLとして扱われることもあります。

対策: 呼び出し元のフローで、サブフロー呼び出し要素の直前に変数値の代入を明示的に行い、デバッグログで値を確認します。代入前に値が存在するかチェックする条件分岐を追加することも有効です。

パターン2: 出力値が更新されない

サブフロー内でレコードを作成・更新し、その結果を出力変数に設定しても、呼び出し元で反映されないことがあります。これは、出力変数に代入する際の変数参照が誤っていたり、サブフロー内の処理がエラーで終了しているにもかかわらず、エラー処理が適切に行われていない場合に発生します。

対策: サブフロー内で出力変数を設定する前に、確実に値が入っていることをログで確認します。また、サブフローに「デフォルト値」や「エラー時処理」を追加し、想定外の状況でも出力が返されるように設計してください。

パターン3: ガバナ制限に抵触する

サブフローを多数呼び出す、またはサブフロー内で大量のDMLを実行すると、SOQLクエリ数やDML行数のガバナ制限に達する可能性があります。その結果、フロー全体が中断され、想定外の動作となります。特に、ループ内でサブフローを呼び出す場合は要注意です。

対策: サブフロー内でバッチ処理を検討する、ループ回数を制限する、またはガバナ制限のモニタリングログを活用します。必要に応じて、JSONのバッチ処理に切り替えることも有効です。

管理者に確認すべき設定と判断基準

問題の切り分けに迷った場合、システム管理者に確認すべき設定項目があります。以下の表を参考に、設定値を確認する優先順位を決めてください。

確認項目	確認方法	判断基準
サブフローのアクセスレベル	フローバージョンの詳細画面で「アクセスレベル」を確認	「システム権限あり」でない場合、参照・更新権限が制限される。権限が必要な処理は「システム権限あり」に変更する。
呼び出し元フローのバージョン	フローリストでアクティブなバージョン番号を確認	古いバージョンがアクティブになっていないか。意図した最新バージョンが有効か確認する。
プロセスビルダーやトリガとの重複	設定 > プロセスビルダー、およびApexトリガのコードを確認	同じレコードに対して複数の自動化が動作している場合、競合や順序問題が発生する。不要な自動化は停止する。
サブフローの入力変数のデフォルト値	サブフローのバージョン詳細で入力変数のプロパティを確認	デフォルト値が設定されていると、呼び出し元から値が渡されない場合にデフォルト値が使われる。意図しないデフォルト値が入っていないか確認する。

また、管理者に伝えるべき情報として、問題の再現手順、期待する動作と実際の動作の差分、デバッグログの該当部分(特にエラーメッセージや変数値)を明確にまとめておくと、原因特定がスムーズになります。Sandboxで再現可能なテストケースを作成しておくことも有効です。

サブフローの動作を検証する具体的な手順

ここでは、サブフローの設定値と処理順を体系的に確認するための手順を紹介します。この手順に沿って検証することで、問題の原因を効率的に特定できるでしょう。

手順1: サブフローの変数の整合性をチェック

1. サブフローのバージョン詳細画面で、各入力変数の「API参照名」「データ型」「必須」の設定を記録します。
2. 呼び出し元のフローで、サブフロー呼び出し要素のプロパティを開き、各入力変数に割り当てられている値を確認します。特に、割り当て元の変数が期待するデータ型と一致しているかチェックします。
3. 出力変数についても同様に、サブフロー側で設定される値の内容と呼び出し元で受け取る変数のマッピングを確認します。
4. サブフロー内で出力変数に値を代入する前に、代入元の値が正しいか、デバッグログで確認します。特に、DML操作の結果を代入する場合は、操作成功後に値を設定するようにフローを組んでください。
5. 必要に応じて、サブフローに一時的な「代入」要素を追加し、出力変数の値を直接検証することもできます。

手順2: 実行順序を可視化する

1. デバッグログから、サブフローの開始と終了のタイムラインを確認します。開始が呼び出し元のどの要素の後で、終了がどの要素の前かを特定します。
2. サブフロー内の要素の順序を、呼び出し元のフロー図と照らし合わせます。特に、サブフロー内でレコードの更新を行う場合、その更新が呼び出し元の後続処理に影響を与えないか確認します。
3. 非同期待機のサブフローを使用している場合は、呼び出し元が待機しないため、サブフローが完了する前に後続の処理が実行される可能性があります。この場合は、キューに入る順番を予測するのは難しいため、出力変数を使わず、トリガやプロセスビルダーで対応することも検討したほうがよいでしょう。

よくある質問(FAQ)

このセクションでは、サブフローに関するよくある質問とその回答をまとめました。

Q1: サブフロー内でエラーが発生した場合、呼び出し元にどのように通知されますか?

A: サブフロー内でエラーが発生すると、サブフローの実行が中断され、サブフローの「エラー時処理」が実行されます。エラー時処理が定義されていない場合、呼び出し元のフローもエラーとして中断されます。エラー時処理を設定し、出力変数にエラーフラグを返すことで、呼び出し元でエラーを検知できます。

Q2: サブフローを再帰的に呼び出すことはできますか?

A: 技術的には可能ですが、Salesforceのフローでは深い再帰は推奨されず、スタックオーバーフローやガバナ制限を引き起こす危険があります。通常は再帰呼び出しを避け、代わりにループ構造やApexのトリガを検討してください。

Q3: サブフローが実行されていないように見える場合、何を確認すべきですか?

A: まず、呼び出し元のフローが正しくサブフローを呼び出しているか、条件分岐が設定されていないかを確認します。次に、サブフローがアクティブなバージョンであることを確認します。また、サブフローの実行権限(アクセスレベル)が適切であるかも重要です。デバッグログでサブフローの開始イベントが記録されていない場合は、呼び出し自体が行われていない可能性が高いです。

まとめ

サブフローが想定と違う動作をする場合の確認ポイントを整理しました。主な原因は、変数のマッピングミス、アクセスレベルの設定、実行順序の誤解に集約されます。デバッグログを活用して処理の流れを可視化し、呼び出し元とサブフローの間で値が正しく受け渡されているか逐一確認することが最も確実な対策です。設定変更の際は、必ずSandboxでテストしてから本番環境に適用することを忘れないでください。本記事の手順を参考に、冷静に原因を切り分けていただければと思います。