Straight answer: a scheduled path is a separate transaction that runs later with a fresh set of governor limits. What it is not is a job running as the Automated Process user. Salesforce documents that scheduled paths run in system context (full data access) while the running user for the flow’s actions stays the user who triggered it. Most scheduled-path surprises come from getting that one detail backwards.
The mechanism, plainly
When a record change meets your entry conditions, the immediate path runs inside the save and any scheduled paths are queued. Setup → Time-Based Workflow lists those pending actions and lets you delete them. When the scheduled time arrives, the platform starts a new interview in its own transaction.
The time is an offset from a time source: when the record was created, when it was last updated, or a date or date/time field on the record. Offsets can be minutes, hours, days, or months.
Treat the scheduled time as “not before”, never “at”. The queue is processed on the platform’s schedule, so a path set five minutes out may run in six. Anything needing precise timing does not belong here.
Keeping the three paths straight matters, because picking the wrong one is a common cause of a scheduled path that “does not work”.
| Immediate path | Asynchronous path | Scheduled path | |
|---|---|---|---|
| When it runs | Inside the save | Right after commit | At a scheduled offset |
| Transaction | The user’s | Its own | Its own |
| Limits | Synchronous, shared | Asynchronous | Asynchronous, shared across a batch |
| Callouts | No | Yes | Yes |
| Failure visible to the user | Yes — the save fails | No | No |
If the requirement is “shortly after the save”, use the asynchronous path rather than a scheduled path a few minutes out. One caveat: asynchronous paths do not support the ISCHANGED operator.
Gotcha 1: the running user is not the Automated Process user
The belief is widespread and it is the wrong model for record-triggered flows. The documented behaviour is two-sided: the path runs in system context, so sharing and field-level security will not block its reads and writes, but the running user for its actions is still the user who triggered the flow.
Consequences worth designing around:
- If the triggering user is deactivated before the path runs, the flow fails when it resumes. A path scheduled 30 days out is a bet on that person still being active in 30 days.
- When a time-based update lands after the triggering user has gone inactive, Salesforce records the org’s Default Workflow User as the editor, which is where the Automated Process confusion starts.
- Event-triggered flows do run as the Default Workflow User, falling back to the Automated Process user when that is unset. Different flow type, different rule.
So never let a scheduled path depend on $User. If it needs to know who acted or which queue to notify, write that onto the record in the immediate path and read it back later.
Gotcha 2: entry conditions are re-checked, but nothing else is
Salesforce cancels already-scheduled paths if a later update causes the record to stop meeting all the entry conditions. That is genuinely useful — a case closed before your 48-hour escalation fires will not escalate.
Two things it does not do. It does not re-evaluate the Decision elements inside the path, so branch logic still needs its own current-state checks. And where the time source is a field value, if that field moves to a new future time while conditions are met, the path executes at the new time whether or not it already ran. Edit a due date twice and you can get two runs.
Gotcha 3: the record is not the record you queued
$Record in a scheduled path carries values from the triggering transaction, and hours or weeks have passed. Someone has edited the record, another flow has changed the owner, the opportunity has closed.
Treat your own path like an integration reading the record fresh: Get Records on the Id, check you got a row, branch on current values rather than queued ones. If the record was deleted there is nothing to act on, and a write against it fails with ENTITY_IS_DELETED.
Gotcha 4: batching, and what it does to limits
Scheduled-path interviews are grouped for execution rather than each getting a private transaction, so the per-transaction allocation is shared across the records processed together. Asynchronous limits apply — 200 SOQL queries and 60,000 ms of CPU rather than the synchronous 100 and 10,000 ms, but shared, so a Get Records inside a loop that was fine on one record becomes a limit exception at scale.
Salesforce documents a configurable batch size of 1 to 200 for schedule-triggered flows, set on the start element. There is no equivalent control for scheduled paths in record-triggered flows, so you cannot tune your way out of this — bulkify the path instead, and test it with a bulk load rather than one record.
Gotcha 5: the limits and the queue
The maximum number of scheduled-path interviews per 24 hours is 250,000, or your user licence count multiplied by 200, whichever is greater. Large orgs never see it. An org running a scheduled path on every contact update during a migration can.
The org-wide cap on paused and waiting flow interviews was removed in a 2024 release, so a long wait no longer eats a scarce allocation. That removes a limit, not the risk: a path waiting three months has three months in which the record, the flow version, and the triggering user can all change under it.
The Time-Based Workflow page is also where you clean up. Deactivating or replacing a flow does not obviously clear what is already queued for it, so after changing a flow with scheduled paths, check that page and delete the pending entries you do not want.
How to test one without waiting
Flow Builder’s debugger can run scheduled paths directly — open Debug, choose the path, and it executes immediately instead of queueing. Use it, but know its limit: debug runs in your transaction, as you, synchronously, so it validates logic and proves nothing about async limits, batching, or a missing triggering user.
For behaviour, four short sandbox tests:
- The happy path, for real. Set the time source to a date/time field, set that field two minutes out, save, and confirm the entry appears in Setup → Time-Based Workflow. Then wait the two minutes and check the record.
- The deleted record. Trigger the path, delete the record, and see what lands in Setup → Paused and Failed Flow Interviews. If your path has no Get Records with a null check, this is the error your users will eventually report.
- The deactivated user. Trigger the path as a test user, deactivate that user, let the path run. This is the failure mode that gets discovered in production, and it takes five minutes to see in a sandbox.
- Two hundred records. Load 200 rows through Data Loader and confirm the queue holds 200 entries. Then count the error emails: one is a record problem, 200 is a design problem.
Frequently asked
Does a scheduled path run if the record no longer meets the entry conditions?
No. Salesforce cancels queued paths when an update makes the record stop meeting all the entry conditions. Your Decision elements inside the path are not re-evaluated, though, so they still need their own checks.
Why did my scheduled path fail with an insufficient access error?
Look at what the path calls rather than the path itself. It runs in system context, but an Apex action or a subflow set to run in user context is evaluated against the triggering user, who may now have a different role, or none.
Can a scheduled path make a callout?
Yes, because it runs in its own transaction after the save has committed. If the callout is the entire point and the timing does not matter, use the asynchronous path instead.
How do I cancel scheduled paths that are already queued?
Setup → Time-Based Workflow, filter to the flow, and delete the pending entries. Deactivating the flow is not a reliable substitute for doing that.
References: the Salesforce Help documents “Scheduled Paths”, “Record-Triggered Flow Considerations”, “How Entry Conditions Work in Record-Triggered Flows”, “General Flow Limits”, “Debug Scheduled Paths in Record-Triggered Flows”, and “Have Unlimited Paused and Waiting Flows”.
