Administrator 練習問題 Q283
Ursa Major Solar では、保証期限の 30 日前にリマインド電子メールを送信するレコードトリガーフローが整備されています。このフローのエントリ条件は［保証期限］が空白でないことだけで、スケジュールパスの時間取得元は［保証期限］項目です。リマインドメールが送信される前に、顧客が保証をさらに 3 年間更新し、［保証期限］が将来の日付に更新されました。フロー内の電子メール要素の予期される動作は何ですか?
左の○で回答を選択。本文を押すと横線で除外でき、もう一度押すと戻せます。
1つ選択してください（0/1）
正答：B. 更新後の保証期限の 30 日前に電子メールが送信されます。
解説
前提知識
レコードトリガーフローとは
フローは、Flow Builderで自動処理を構築する機能です。そのうち「レコードトリガーフロー」は、レコードが作成・更新・削除されたことをきっかけに自動で動くフローを指します。「保証期限の30日前にリマインドメールを送る」仕組みでは、保存後のレコードトリガーフローにスケジュールパスを設定します。
スケジュールパスとは
レコードトリガーフローは、原則としてレコードが保存された「その瞬間」に動きます。しかし「期限の30日前」のように将来の特定の時点で処理したいことがあります。そのために用意されているのがスケジュールパスです。 スケジュールパスは「基準となる日付／日時項目（時間取得元）から何日前・何日後」という形で実行時刻を予約します。待機中の処理は、［設定］の［時間ベースの自動化］で確認できます。 レコードが更新されたときの動作は、更新後のエントリ条件と時間取得元の値で決まります。
- 更新後にエントリ条件を満たさなくなった → 既存のスケジュール済みパスは取り消される
- 条件を満たしたまま、時間取得元の日付が将来へ変更された → 新しい日付を基準に再スケジュールされる
💡 ここがまだモヤッとする方へ：フローが「いつ」動くのか、保存前・保存後・スケジュールパスの違いを整理した記事があります。 レコードトリガーフローの実行タイミングを理解する
エントリ条件とは
フローの開始要素に設定する「どのレコードをフローの対象にするか」という条件です。本問のエントリ条件は［保証期限］が空白でないことだけなので、保証を延長しても条件は真のままです。
設問の状況を分解する
- 当初の保証期限を基準に、「期限日の30日前」にメールを送るスケジュールパスが予約されている。
- 送信前に顧客が保証を3年延長し、［保証期限］が将来の日付へ変更された。
- エントリ条件は［保証期限］が空白でないことだけなので、更新後も条件は真のままである。
- 時間取得元の日付だけが将来へ変わったので、予約は新しい保証期限の30日前へ再スケジュールされる。 初学者が誤解しやすいのは、「日付が変わったのだから予約は消える」と考えてしまう点です。予約が消えるのは、あくまでエントリ条件を満たさなくなったときです。
選択肢の検討
A. 顧客の電子メールアドレスが見つからなかったため、電子メールは送信されませんでした。 → ✕
設問には宛先アドレスが欠落しているという条件がありません。時間取得元の変更後にスケジュール済みパスがどうなるかを問う設問なので、この選択肢を支持する根拠はありません。
B. 更新後の保証期限の30日前に電子メールが送信されます。 → ⭕ 正解
エントリ条件は更新後も真で、時間取得元である［保証期限］の日付が将来へ変更されました。この場合、既存のスケジュール済みパスは新しい保証期限を基準とした時刻へ再スケジュールされ、その時点でメール要素が実行されます。つまり、3年後の新しい期限の30日前にリマインドが届きます。
C. レコードが基準を満たさなくなったため、電子メールは送信されません。 → △（惜しいが不正解）
確かに、更新によってエントリ条件を満たさなくなった場合は、既存のスケジュール済みパスは取り消されます。しかし本問のエントリ条件は［保証期限］が空白でないことだけで、延長しても条件は真のままです。エントリ条件が「保証期限が今日から60日以内」などとなっていて、延長によって条件外になる場合は、この選択肢が正解になります。
D. メールは、条件が満たされるまでジョブキューにロックされます。 → ✕
スケジュール済みパスは、条件が満たされるまで無期限にロックされる仕組みではありません。予約された日時に実行されるか、エントリ条件を満たさなくなれば取り消されるか、時間取得元の変更によって再スケジュールされます。
管理者としての対処手順
- ［設定］のクイック検索で［時間ベースの自動化］を開き、対象レコードの待機中のスケジュール済みパスを確認する。
- Flow Builderで対象フローの［開始］要素を開き、エントリ条件と［更新されたレコードでフローを実行するタイミング］を確認する。
- スケジュール済みパスの時間取得元が［保証期限］項目か、オフセットが30日前かを確認する。
- テストレコードで保証期限を延長し、［時間ベースの自動化］の実行予定日時が新しい日付の30日前に変わっていることを確認する。
| レコード更新後の状態 | スケジュール済みパスの動作 |
|---|---|
| エントリ条件が偽になる | 既存の予約は取り消される |
| 条件は真のまま、時間取得元の日付が将来へ変わる | 新しい日付とオフセットを基準に再スケジュールされる |
| 条件も時間取得元も変わらない | 既存の予約は維持される |
あわせて覚えておきたいポイント
- スケジュールパスの問題は、まず「エントリ条件はまだ真か」、次に「時間取得元の日付が変わったか」の順で考えます。
- 条件が偽になれば予約は取り消し、真のまま日付が将来へ動けば再スケジュールです。
- 待機中のスケジュール済みパスは［時間ベースの自動化］で確認できます。トラブルシュートの最初の確認先です。
- 多数のパスが同じ時間帯に集中する場合は、設定されたバッチサイズに従って順次処理されます。
出典（Salesforce公式）
- スケジュール済みパス（Salesforce Help） — 「更新後に条件を満たさなくなれば既存の予約は取り消され、条件が真のまま時間取得元の日付を変更すると新しい日付を基準に再スケジュールされる。待機中のパスは［時間ベースの自動化］で確認できる」
- How Entry Conditions Work in Record-Triggered Flows（Salesforce Help） — 「レコード更新時にエントリ条件が再評価され、条件を満たさなくなった場合にスケジュール済みパスが取り消される」