Scheduled Action
A scheduled action in Salesforce is an automated action that runs at a set time relative to a record event instead of firing the instant criteria are met.
Definition
A scheduled action in Salesforce is an automated action that runs at a set time relative to a record event instead of firing the instant criteria are met. The timing is usually expressed as an offset, such as 3 days after a Case is created or 1 hour before an Opportunity close date.
Scheduled actions power time-based automation like reminders, follow-ups, and escalations. Today you build them with scheduled paths inside record-triggered flows. The same idea existed in the older Workflow Rules (time-dependent actions) and Process Builder (scheduled actions), both of which reached end of support on December 31, 2025.
How time-based automation works in Salesforce
The offset model: a base time plus a delay
Every scheduled action is built from two pieces. The first is a base time, which is the moment the clock starts. The second is an offset, which is how far before or after that moment the action runs. In a record-triggered flow you pick a Time Source field (for example Close Date or the record creation time), an Offset Number, and an Offset Option such as Days After or Days Before. Set those three values and the platform calculates exactly when the action should execute. This model is what makes the feature useful for real business timing. A renewal reminder might fire 30 days before a contract end date. An escalation might fire 4 hours after a high-priority Case is opened with no owner action. Because the base time can be any date or date/time field on the record, you are not limited to the moment the automation triggered. You can anchor work to dates that matter to the business, then let Salesforce hold the action in a queue until that calculated time arrives.
Scheduled paths in record-triggered flows
The modern way to create a scheduled action is a scheduled path. A record-triggered flow can have an immediate path that runs in the same transaction as the record save, plus one or more scheduled paths that run later. Scheduled paths are available only when the flow uses the Actions and Related Records option, meaning the after-save part of the flow. You cannot attach one to a before-save (fast field update) flow. Each scheduled path runs in its own asynchronous transaction, separate from the user action that triggered it. That separation matters for governor limits, because the delayed work does not share limits with the original save. A scheduled path can run minutes, hours, days, or even months after the record change. You can also add an optional condition on the path so that the flow only does its work if the record still qualifies when the time arrives. Salesforce surfaces pending and completed runs on the Time-Based Automations page in Setup, and each flow lists its paths in Flow Trigger Explorer.
Schedule-triggered flows are a different tool
It is easy to confuse two flow types that both involve a schedule. A scheduled path lives inside a record-triggered flow and runs once per qualifying record, offset from an event on that record. A schedule-triggered flow is a separate flow type that runs on a clock you set, such as once, daily, or weekly at a chosen time. It can process a batch of records returned by a filter, so it suits nightly cleanup, recurring reports, or bulk status updates. Pick by the question you are answering. If you want something to happen a fixed time after each individual record changes, use a scheduled path. If you want a routine sweep across many records at a regular time regardless of any single record event, use a schedule-triggered flow. Both replace older patterns, and both let you avoid writing an Apex scheduled job for common time-based needs. They can coexist in the same org, and many teams use both for different parts of the same process.
How the legacy tools handled scheduled actions
Before Flow, two declarative tools owned time-based automation. Workflow Rules had time-dependent actions tied to time triggers. You added a time trigger to a rule, set it to a number of days or hours before or after a date field, then attached actions like a field update or an email alert. The valid range for a workflow time trigger is 0 to 999 days or hours. Queued actions stayed in the time-based workflow queue and were removed automatically if the record stopped matching the rule criteria. Process Builder offered scheduled actions on a similar principle. When a process scheduled an action, Salesforce created a paused flow interview and held it until the scheduled time. An org can process up to 1,000 groups of scheduled actions per hour, where a group is all actions tied to one schedule. If a schedule resolved to a time already in the past, the actions ran as soon as possible, usually within an hour. Both tools re-checked criteria and canceled pending work when a record no longer qualified.
Why the platform moved to Flow
Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025. Existing automations of those types keep running, and you can still activate, deactivate, and edit them, but bugs will not be fixed and no new features arrive. For anything new, Salesforce directs admins to Flow Builder. A Migrate to Flow tool helps convert existing rules and processes, including their scheduled pieces, into flows. The move is about consolidation as much as power. Flow brings before-save and after-save logic, scheduled paths, schedule-triggered runs, branching, loops, and screen interaction under one builder. That reduces the number of places automation can hide for an object. Flow Trigger Explorer then shows every flow that fires for an object and trigger, grouped by when it runs, so the order of execution is visible. A scheduled action built as a scheduled path is also easier to debug than a queued workflow time trigger, because you can inspect the paused interview and re-run paths during testing.
Reliability, monitoring, and common pitfalls
Scheduled actions run later and out of band, so a few habits keep them dependable. Set the org Default Workflow User in Process Automation Settings, because that user runs the scheduled work and a missing value can stop paths from executing. Add a condition to the path when the underlying record can change between the trigger and the run time, so a closed Case does not still receive a chase email. Keep offsets sensible. A path set to one minute after creation can feel unreliable next to the same logic at one hour, simply because of queueing and processing time. Monitor what is pending. The Time-Based Automations page lists individual flow instances waiting to run, which lets you spot and clear stuck items before users notice. Watch volume too, since high-throughput objects can queue large numbers of delayed actions. When debugging, remember the work happens in a separate asynchronous transaction, so failures show up in flow error emails and the paused interview view rather than in the original user save.
How to build a scheduled action with a scheduled path
The current way to build a scheduled action is a scheduled path inside an after-save record-triggered flow. The steps below assume Flow Builder and an object that already has a date or date/time field to anchor the timing.
- Create an after-save record-triggered flow
In Setup, open Flow Builder and create a Record-Triggered Flow. Choose the object, set the trigger (created, updated, or created or updated), and pick the Actions and Related Records option so the flow runs after save. Scheduled paths are not available on before-save flows.
- Add a scheduled path
On the Start element, add a Scheduled Path. Give it a label, then define the timing with a Time Source (a field like Close Date or the record creation time), an Offset Number, and an Offset Option such as Days After or Hours Before.
- Set an optional run condition
Add entry conditions to the path so it only proceeds if the record still qualifies at run time. This stops actions firing against records that changed after the flow first triggered, for example a Case that was already closed.
- Build the action and activate
Drag elements onto the scheduled path to do the work, such as an Update Records or Send Email element. Debug the flow, confirm the Default Workflow User is set in Process Automation Settings, then activate.
The base field the offset is measured from, such as Close Date, Created Date, or a custom date/time field on the record.
How far before or after the Time Source the path runs, expressed in minutes, hours, or days (for example 3 Days After).
Optional criteria re-checked when the time arrives, so the path runs only if the record still matches.
The user, set in Process Automation Settings, that executes scheduled paths and other background automation.
- Scheduled paths work only with the Actions and Related Records (after-save) option, not before-save flows.
- Each scheduled path runs in a separate asynchronous transaction, so it does not share governor limits with the original record save.
- If the Default Workflow User is not configured, scheduled paths can fail to run.
- Very short offsets like one minute are less reliable than one hour or more because of queueing and processing time.
Prefer this walkthrough as its own page? How to Scheduled Action in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Scheduled PathsSalesforce
- How Does Salesforce Process Scheduled Actions?Salesforce
- Considerations for Time-Dependent Actions and Time TriggersSalesforce
Straight from the source - Salesforce's reference material on Scheduled Action.
- Scheduled PathsSalesforce
- Schedule-Triggered Flow ConsiderationsSalesforce
Hands-on resources to go deeper on Scheduled Action.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Scheduled Action in Salesforce automation?
Q2. Which modern surface does Salesforce recommend for new Scheduled Action work?
Q3. Why should a Scheduled Action re-check its condition when it finally fires?
Discussion
Loading discussion…