Scheduled Paths and Schedule-Triggered Flows

Why This Topic Matters

Advanced Process Automation is one of the most heavily weighted domains on the Salesforce Advanced Administrator exam, and time-based automation sits right at its heart. Workflow Rules and Process Builder are retired for new automation, so every scenario that used to be solved with time-dependent workflow actions or scheduled actions in Process Builder must now be solved with Flow. The two Flow tools that handle 'do something later' or 'do something on a schedule' are Scheduled Paths (inside a record-triggered flow) and Schedule-Triggered Flows (a standalone flow type). The exam loves to present a business requirement and ask which of these two you should use, what limitations apply, and how you monitor or troubleshoot the result. If you can quickly tell the difference between 'relative to a record event' and 'absolute, recurring time', you will pick up easy points.

What Scheduled Paths Are

A Scheduled Path is an optional branch within a record-triggered flow. Instead of running immediately when a record is created or updated, the actions on a scheduled path run at a time that is relative to something about that record. You can base the schedule on one of two time sources:

1. The trigger time - when the record was created or updated and met the entry conditions (for example, 2 days after an Opportunity is created).
2. A date or date/time field on the record - such as Close Date, Contract End Date, or a custom Renewal Date field (for example, 7 days before Contract End Date, or 1 hour after Scheduled Appointment Time).

The offset can be measured in minutes, hours, days, or months, and it can be before or after the time source. A single record-triggered flow can have multiple scheduled paths, each with its own offset and its own set of elements (Update Records, Create Records, Send Email, Post to Chatter, Subflow, Action, and so on). Each scheduled path can also have its own batch size, which defaults to 200 records per transaction and can be lowered to as little as 1 to avoid governor limit problems when calling external systems or complex Apex.

Key conditions for scheduled paths:
- They are available only in record-triggered flows that are optimized for Actions and Related Records (After Save). They are not available in Fast Field Updates (Before Save) flows.
- They are available for Create, Update, and Create or Update triggers, but not for Delete triggers.
- The flow must have entry conditions defined if you want to use the option 'Only when a record is updated to meet the condition requirements', which is the typical configuration so the schedule is set once when the record qualifies rather than on every edit.
- Do not confuse a Scheduled Path with the Run Asynchronously path. The asynchronous path runs almost immediately after the triggering transaction commits (in a separate transaction), while a scheduled path waits for a specific time.

How Scheduled Paths Work Behind the Scenes

When a record meets the entry conditions, Salesforce creates a paused flow interview for each scheduled path and stores the calculated execution time. You can see and manage these pending interviews in Setup under Time-Based Workflow (yes, the legacy name is still used) and under Flow Interviews (Paused and Waiting Interviews). From the Time-Based Workflow page you can filter by flow and even delete pending interviews if you need to cancel them.

When the scheduled time arrives, Salesforce re-evaluates the record. If the record no longer meets the entry conditions, the scheduled path does not run. If the date field used as the time source changes while the interview is pending, the scheduled time is recalculated to reflect the new value. Scheduled paths run in system context without sharing, so field-level security and sharing rules are not enforced. Because the original user's session is long gone, references to the current user can behave differently than in the immediate path; emails and record changes made by scheduled paths are commonly attributed to the Automated Process user, so avoid designs that depend on the triggering user's profile at execution time.

Limits to remember: the number of records that can be processed by scheduled paths and schedule-triggered flows combined in a rolling 24-hour period is 250,000 or the number of user licenses multiplied by 200, whichever is greater. If you deactivate a flow, pending scheduled interviews for that flow version are still executed by that version unless deleted, so clean-up is part of change management.

What Schedule-Triggered Flows Are

A Schedule-Triggered Flow is a completely separate flow type. It does not react to a record being saved. Instead, it runs at a specific date and time you choose, with a frequency of Once, Daily, or Weekly. The schedule is based on the org's default time zone. Nothing in Flow Builder lets you pick hourly or monthly frequencies natively; if an exam question asks for an hourly schedule, the expected answer typically involves a scheduled Apex class, multiple schedule-triggered flows, or a different design.

Optionally, you specify an object and filter conditions. If you do, the flow runs once for each record that matches at the scheduled time, and the current record is available in the $Record global variable. If you do not specify an object, the flow runs a single time as one interview, which is useful for summary emails, cleanup logic driven by Get Records, or kicking off subflows.

Key characteristics:
- Schedule-triggered flows run in system context without sharing and the running user is the Automated Process user. Emails sent from the flow show Automated Process as the sender unless you configure a specific org-wide address, and record history shows Automated Process as the modifier.
- They cannot contain Screen elements or Pause elements, and they cannot be launched from a button or page.
- The flow must be Active for the schedule to run. You can debug the flow in Flow Builder, but debugging does not execute the actual schedule.
- Each matching record is processed in its own interview, and interviews are batched (default 200 per transaction) to respect governor limits. Total daily record volume counts toward the same 250,000-or-licenses-times-200 limit shared with scheduled paths.
- You can monitor upcoming runs in Setup under Scheduled Jobs, and completed or failed runs through flow error emails and Flow Interviews. To change the schedule you must create a new version of the flow; the start time and frequency are stored on the Start element.

Choosing Between Them

The single most important skill for the exam is recognizing the trigger style in the scenario:

- Use a Scheduled Path when the timing is relative to a record event or a date on that specific record, and the record will be created or updated in a way that can start the clock. Examples: send a follow-up email 3 days after a Case is created; notify the owner 14 days before an Opportunity Close Date; escalate a Case 4 hours after Status becomes Escalated; replace an existing time-dependent workflow action. The Migrate to Flow tool converts time-dependent workflow actions into scheduled paths.

- Use a Schedule-Triggered Flow when the timing is absolute and recurring, or when you need to act on records that may never be edited again. Examples: every night at 1 AM, close Cases that have been in Resolved status for 30 days; each Monday morning, send a digest of overdue Tasks; once a week, update a rollup field on all Accounts; run a one-time data correction next Saturday. A scheduled path cannot help here because nothing happens to those records to fire a record-triggered flow.

Some requirements can be met either way (for example, 'remind users 7 days before Contract End Date'). In those cases the exam usually expects the scheduled path because it is tied to the record and requires less overhead, unless the scenario stresses that records already exist, bulk processing is needed, or the schedule should run regardless of record changes.

Exam Tips: Answering Questions on Scheduled Paths and Schedule-Triggered Flows

1. Hunt for timing keywords. Phrases like 'X days after creation', 'X hours before a date field', 'when the record meets criteria and then wait' point to a Scheduled Path. Phrases like 'every day at', 'weekly', 'nightly batch', 'regardless of whether the record changes' point to a Schedule-Triggered Flow.

2. Remember the flow optimization rule. If the question says the flow is a Before Save (Fast Field Updates) flow or a Delete-triggered flow, scheduled paths are not an option. The correct answer will involve an After Save (Actions and Related Records) flow on Create, Update, or Create or Update.

3. Frequency is Once, Daily, or Weekly only. If a question asks for every hour or monthly, eliminate the plain schedule-triggered flow answer and look for scheduled Apex or a workaround.

4. Know where to monitor and cancel. Pending scheduled path interviews live in Time-Based Workflow and Flow Interviews. Upcoming schedule-triggered flow runs appear under Scheduled Jobs. Questions about 'an admin needs to stop emails that are already queued' point to deleting the paused interviews.

5. Entry conditions are re-checked. If the scenario says the record was updated so it no longer qualifies before the scheduled time, the scheduled path will not fire. This is intentional behavior, not a bug, and it is the answer to 'why did the email not send'.

6. Automated Process user implications. Expect a question where sent emails show Automated Process as the sender, or where field history shows Automated Process. This is expected for schedule-triggered flows and for scheduled path actions. If the requirement demands the record owner's name on the email, configure an org-wide email address or send the email through a different mechanism.

7. Batch size is a troubleshooting lever. When a scheduled path or schedule-triggered flow hits governor limits because it calls Apex or external callouts, reducing the batch size (down to 1) is the recommended fix, not rewriting as a workflow rule.

8. Do not confuse Run Asynchronously with Scheduled. Asynchronous path means 'right after save, separate transaction' and is used for callouts or to avoid mixed DML; it is not a timing mechanism.

9. Migration questions. If a workflow rule with time-dependent actions needs to move to Flow, the answer is a record-triggered flow with a scheduled path, often created with the Migrate to Flow tool. Process Builder scheduled actions map to scheduled paths the same way.

10. System context without sharing. Both tools ignore sharing rules and field-level security. If a question asks why a flow updated records the user could not normally see, this is the explanation.

11. Eliminate retired tools. Any answer option that recommends creating a new Workflow Rule or Process Builder process for time-based automation is a distractor. Salesforce expects Flow.

12. Watch the daily limit. If the scenario mentions millions of records processed nightly and flow failures, the limit of 250,000 records or 200 times the user license count per 24 hours (shared across both tools) is the likely cause, and Batch Apex is the typical alternative.

Quick Summary Table (in prose)

Scheduled Path: lives inside a record-triggered After Save flow; triggered by record creation or update; timing is an offset in minutes, hours, days, or months before or after the trigger time or a date field; one paused interview per record; re-evaluates entry conditions at run time; monitored under Time-Based Workflow; adjustable batch size; replaces time-dependent workflow actions.

Schedule-Triggered Flow: standalone flow type; triggered by the clock at a chosen date and time; frequency Once, Daily, or Weekly in the org default time zone; optional object and filters with $Record per record; runs as Automated Process user in system context; monitored under Scheduled Jobs; ideal for nightly or weekly batch work on records that may never change.

Master these distinctions, memorize the limits and monitoring locations, and you will handle every time-based automation question the Advanced Administrator exam throws at you.