Salesforceでスケジュールトリガーフローを作成したものの、指定した時刻を過ぎてもレコードが更新されない、ToDoが作成されない、といったことがあります。
Flow Builderのデバッグでは正常に完了していると、フロー自体に問題はないように見えます。しかし、実際のスケジュール実行では、有効化したバージョン、開始日時、開始条件、実行ユーザーなども結果に影響します。
この記事では、Salesforce Developer Editionに検証用のスケジュールトリガーフローを作成し、デバッグと実際のスケジュール実行を比較します。動かないときに確認したい項目を、実際に調べる順番で整理します。
先に結論です。設定した時間に動かない場合は、まず「組織のデフォルトタイムゾーン」と「個人のタイムゾーン」の差を確認してください。スケジュールトリガーフローは、組織のデフォルトタイムゾーンを基準に実行されます。今回、私が想定した時間に実行されなかった原因も、この差を見落としていたことでした。そのうえで、有効なバージョン、開始条件、実行ユーザー、ログの順に確認すると切り分けやすくなります。
スケジュールトリガーフローが動かないときの確認項目
先に確認項目をまとめると、次の順番で見ていくと原因を絞り込みやすくなります。
| 確認する項目 | 主な確認内容 |
|---|---|
| 開始日時・タイムゾーン | 開始日時と、組織・個人のタイムゾーンの差を把握できているか |
| 有効なバージョン | 修正した最新版が有効になっているか |
| 開始条件 | 実行時点で条件に一致するレコードが存在するか |
| デバッグ条件 | 「開始条件の要件をスキップ」が有効になっていないか |
| 実行ユーザー | デフォルトのワークフローユーザーが設定されているか |
| 権限・入力規則 | 対象オブジェクトや項目を更新できるか |
| デバッグログ | フローが起動したか、何件が対象になったか、どこで失敗したか |
注意：設定時刻に動かない場合は、開始条件より先にタイムゾーンを確認してください。Salesforceでは組織のデフォルトタイムゾーンが実行時刻の基準です。今回、私が設定した時間に実行されなかった原因は、組織と個人のタイムゾーンの差を見落としていたことでした。
ボンボンデバッグが成功していても、実際のスケジュール実行が成功するとは限らないよ。まずは「デバッグ時と実行時で何が違うか」を見ていこう。
今回作成する検証用フロー
今回は、条件に一致する取引先を対象に、実行確認用のToDoを作成するスケジュールトリガーフローを用意します。処理を複雑にしすぎず、フローが起動したかどうかをレコード上で確認できる構成です。
| 検証環境 | Salesforce Developer Edition |
|---|---|
| フロー種別 | スケジュールトリガーフロー |
| 対象オブジェクト | 取引先 |
| 開始条件 | 取引先名が「STF検証」で始まる |
| 実行内容 | 対象取引先に実行確認用のToDoを作成 |
| 検証日 | 2026年7月20日 |
ボンボン検証用の組織がある人は、同じ構成で試してみてね。組織と自分のタイムゾーンの差を確認して、組織側の時刻を基準にすると分かりやすいよ。
検証用レコードとして、条件に一致する「STF検証_対象」と、条件に一致しない「通常取引先_対象外」を作成します。2件を用意することで、開始条件をスキップしたデバッグと実際のスケジュール実行の違いも確認します。
スケジュールトリガーフローを作成する
1．新しいスケジュールトリガーフローを作成する
「設定」から「フロー」を開き、「新規フロー」を選択します。フロー種別で「スケジュールトリガーフロー」を選び、Flow Builderを開きます。
2．開始日時と対象レコードを設定する
「開始」要素で、検証しやすい日時と実行頻度を設定します。対象オブジェクトには「取引先」を選び、取引先名が「STF検証」で始まることを開始条件にします。
開始日時は、保存や有効化の作業時間も考慮して設定します。設定中に開始時刻を過ぎてしまうと、想定したタイミングで確認できません。
3．実行確認用のToDoを作成する
「レコードを作成」要素を追加し、ToDoを1件作成するように設定します。件名は「スケジュールトリガーフロー実行確認」など、検証用だと分かる内容にします。
| ToDoの項目 | 設定内容 |
|---|---|
| 件名 | スケジュールトリガーフロー実行確認 |
| 関連先ID | トリガーレコードの取引先ID |
| 割り当て先ID | 取引先の所有者ID |
| 状況 | 未着手 |
検証環境によっては、ToDoの必須項目や選択肢が異なる場合があります。保存時にエラーが出た場合は、その組織で必須になっている項目も設定します。
4．保存して有効化する
フロー名とAPI参照名を設定して保存します。保存しただけではスケジュール実行されないため、検証に使用するバージョンを有効化します。
修正を繰り返した場合は、編集したバージョンと有効なバージョンが一致しているかも確認します。デバッグしたバージョンだけ直っていて、実際には古いバージョンが有効になっている可能性があるためです。
Flow Builderのデバッグで確認する
フローを有効化する前後で、Flow Builderの「デバッグ」から処理を確認します。スケジュールトリガーフローのデバッグでは、対象レコードを選んで1件分の処理を実行できます。
条件に一致するレコードで処理本体を確認する
最初に「STF検証_対象」を選び、「開始条件の要件をスキップ」を有効にしてデバッグしました。この操作で確認できるのは、対象レコードが処理本体へ渡されたあと、各要素がどの順番で実行され、ToDoの作成まで進むかです。
デバッグはToDo作成まで完了しました。今回はロールバックモードを有効にしていないため、デバッグでも実際にToDoが作成されています。
条件に一致しないレコードでも同じデバッグを試す
次に、条件に一致しない「通常取引先_対象外」を選び、同じく「開始条件の要件をスキップ」を有効にしてデバッグしました。この場合もToDo作成まで完了しました。
ただし、実際のスケジュール実行では開始条件が適用されます。つまり、条件をスキップしたデバッグの成功は処理本体の確認であり、実行対象として抽出されることの証明にはなりません。
実際のスケジュール実行結果を確認する
デバッグが完了したら、フローを有効化した状態で設定時刻を待ちます。実行後、検証用の2件の取引先にToDoが作成されたかを確認します。
| 検証レコード | 開始条件 | デバッグ結果 | 実スケジュール結果 |
|---|---|---|---|
| STF検証_対象 | 一致 | 作成 | 作成 |
| 通常取引先_対象外 | 不一致 | 作成 | 未作成 |
実スケジュールでは、開始条件に一致する「STF検証_対象」にだけ、設定時刻の3時15分にToDoが作成されました。一方、条件に一致しない「通常取引先_対象外」には作成されませんでした。
今回の結論は、「デバッグ成功」と「スケジュール実行時の対象レコード抽出」は分けて確認する必要がある、ということです。デバッグで処理本体が動いても、開始条件・開始日時・有効なバージョンに問題があれば、実スケジュールでは動きません。
動かないときの切り分け手順
1．開始日時と組織のデフォルトタイムゾーンを確認する
最初に、開始日時が未来になっているか、すでに時刻を過ぎていないかを確認します。次に「設定」→「会社の設定」→「組織情報」で、組織のデフォルトタイムゾーンを開きます。個人設定のタイムゾーンと異なる場合は、その時差も確認します。
Salesforce公式Trailheadでも、スケジュールトリガーフローは組織のデフォルトタイムゾーンを基準にすると説明されています。組織の設定を変更すると、ほかの処理の時刻にも影響する可能性があるため、安易に変更せず、まず組織側の時刻を基準に開始日時を確認します。
今回、私は画面で設定した時間にフローが動かず、最初は開始条件や有効化を疑いました。実際の原因は、組織と個人のタイムゾーンの差を見落としていたことでした。組織のデフォルトタイムゾーンを基準に設定時刻を見直すと、想定時刻とのずれを切り分けられました。
検証するときは、開始日時、組織のデフォルトタイムゾーン、個人のタイムゾーンをメモしておくと、単なる時刻のずれなのか、フローが起動していないのかを判断しやすくなります。
2．修正したバージョンが有効か確認する
Flow Builderで修正しただけでは、実行されるバージョンは切り替わりません。フローの詳細画面から有効なバージョンを確認します。
デバッグしたバージョンと有効なバージョンが違う場合は、デバッグでは成功するのに実行結果が変わらない原因になります。
3．実行時点で開始条件に一致するか確認する
スケジュールトリガーフローは、設定したオブジェクトと開始条件に一致するレコードを対象に処理します。フローが有効でも、一致するレコードが0件なら、期待した更新やToDo作成は行われません。
日付や日時を条件にしている場合は、数式の基準日、タイムゾーン、空欄の扱いも確認します。まずは対象レコードをリストビューやSOQLで絞り込み、同じ条件で何件になるかを見る方法が分かりやすいです。
4．デバッグで開始条件をスキップしていないか確認する
デバッグ時に開始条件をスキップすると、実際には対象外のレコードでも処理部分だけを確認できます。これは処理の確認には便利ですが、開始条件の検証にはなりません。
「デバッグでは動くのに実際には動かない」ときは、開始条件を適用したデバッグも行い、実行対象の抽出と処理本体を分けて確認します。
5．デフォルトのワークフローユーザーを確認する
Salesforce公式ヘルプでは、スケジュールトリガーフローはデフォルトのワークフローユーザーとして実行されると案内されています。
「設定」→「プロセスの自動化設定」を開き、「デフォルトのワークフローユーザー」を確認します。ユーザーが未設定、無効化済み、または処理に必要なアクセスを持っていない場合は、実行時の動作へ影響する可能性があります。
古い解説では「自動化プロセスユーザーを追跡する」と書かれていることがあります。現在の組織でログを取得するときは、先にデフォルトのワークフローユーザーを確認し、実際の実行ユーザーを追跡対象にします。
6．権限・入力規則・後続の自動化を確認する
フローが起動していても、レコード作成や更新の段階で失敗することがあります。対象オブジェクトと項目へのアクセス、入力規則、重複ルール、Apexトリガー、別のレコードトリガーフローなどを確認します。
Flow Builderの画面でエラーになった要素だけを原因と決めつけず、その要素から実行された後続処理も含めて確認する必要があります。
デバッグログで実行状況を確認する
画面上の確認だけで原因が分からない場合は、デバッグログを取得します。ログを確認すると、スケジュールトリガーフローが起動したか、対象レコードが何件あったか、どの処理で失敗したかを追いやすくなります。
1．実行ユーザーへ追跡フラグを設定する
「設定」→「デバッグログ」を開き、「新規」を選択します。追跡対象には、先ほど確認したデフォルトのワークフローユーザーを指定します。
追跡期間に実際の実行時刻が含まれるように、開始日時と有効期限も確認します。
2．ログでフローの開始とエラーを探す
設定時刻を過ぎたら、デバッグログの一覧を更新します。対象時刻のログを開き、フロー名、エラー、レコード作成・更新に関する記録を確認します。
Salesforce公式ヘルプでは、スケジュールトリガーフローが実行するレコード数を追跡する方法として、デバッグログのSCHEDULED_FLOW_DETAILイベントを案内しています。
今回のログはステータスが「Success」で、SCHEDULED_FLOW_DETAILには取得レコード数が1件と記録されていました。実スケジュールで開始条件に一致する1件だけが抽出され、フローが完了したことをログからも確認できました。
3．ログが出ない場合に確認する
ログ自体が見つからない場合は、次の点を確認します。
- 追跡対象ユーザーが実際の実行ユーザーと一致しているか
- 追跡フラグの有効期間に実行時刻が含まれているか
- フローが有効化されているか
- 開始日時と実行頻度が正しいか
- 組織のタイムゾーンを取り違えていないか
大量レコードを処理するときの注意点
Salesforce公式ヘルプでは、24時間あたりに実行できるスケジュールトリガーフローインタビュー数の上限は、250,000件または組織のユーザーライセンス数×200の大きい方とされています。
また、フローは開始条件に一致したレコードごとに実行されます。大量のレコードを処理する場合は、件数上限だけでなく、フロー内のSOQL、DML、CPU時間などのガバナ制限も考慮します。
検証では、最初から大量のレコードを対象にせず、1件から数件のテストデータで実行結果とログを確認してから対象を広げる方が安全です。
スケジュール済みパスとの違い
スケジュールトリガーフローと、レコードトリガーフローのスケジュール済みパスは、どちらも指定したタイミングで処理を実行できますが、起点が異なります。
| 機能 | 主な起点 | 向いている処理 |
|---|---|---|
| スケジュールトリガーフロー | 決められた日時・頻度 | 毎日や毎週、条件に一致するレコードをまとめて確認する |
| スケジュール済みパス | レコードの作成・更新 | レコードの変更後や日付項目を基準に、一定時間後に処理する |
「毎日、期限切れのレコードを探したい」ならスケジュールトリガーフロー、「商談の完了予定日の3日前に処理したい」など、特定レコードの変更や日付を起点にしたい場合はスケジュール済みパスが候補になります。
まとめ
スケジュールトリガーフローが設定時刻に動かないときは、まず開始日時と、組織のデフォルトタイムゾーンを確認します。個人のタイムゾーンと異なる場合は、その差も考慮します。今回のように、フロー自体ではなく時刻の見え方が原因になっている場合があります。
タイムゾーンに問題がなければ、有効なバージョン、開始条件、実行ユーザーを順番に確認します。開始条件をスキップしたデバッグは処理本体の確認には使えますが、実スケジュールで対象レコードとして抽出されることまでは確認できません。
今回の検証では、デフォルトのワークフローユーザーに追跡フラグを設定したところ、ログに取得レコード数1件と記録され、条件に一致する取引先だけが実行対象になったことを確認できました。画面だけで原因を絞れない場合は、実行ユーザーとログまで確認すると切り分けやすくなります。
コメント