Time-Dependent Workflow Action
A time-dependent workflow action is an automated action inside a Salesforce workflow rule that runs at a future moment instead of firing the instant a record meets the rule's criteria.
Definition
A time-dependent workflow action is an automated action inside a Salesforce workflow rule that runs at a future moment instead of firing the instant a record meets the rule's criteria. The action is held in a time-based queue and released when a time trigger reaches its scheduled point, measured as a number of days or hours before or after a date field on the record.
Time-dependent actions belong to Workflow Rules, an older automation feature. Salesforce ended support for Workflow Rules on December 31, 2025, so existing rules still run but receive no fixes. New scheduled automation should be built in Flow Builder using scheduled paths, and the Migrate to Flow tool can convert older rules that still carry pending time-based actions.
How Salesforce schedules and releases a time-dependent action
The time trigger that anchors the action
A time-dependent action never exists on its own. It hangs off a time trigger, and the trigger is what tells Salesforce when to run the work. You define a trigger by picking a date or date/time field on the object, then setting an offset of days or hours either before or after that field. The valid range for the offset is 0 to 999 days or hours, so you can schedule anything from the moment a date arrives out to almost three years away. A renewal reminder might fire 30 days before a contract End Date. An escalation task might fire 2 hours after a Case was opened. Each trigger can hold its own group of immediate-style actions, which is why one workflow rule can carry several different schedules at once. The field you choose has to hold a value when the rule fires, because Salesforce calculates the run time from it. If the date field is blank, that record gets no scheduled action. This anchoring to a real field is the whole point of the feature, and it is also the part most teams forget to validate.
What the time-based workflow queue actually does
When a record meets a workflow rule that has a time trigger, Salesforce does not run the action right away. It places an entry in the time-based workflow queue, sometimes called the time-based queue, holding the record and the moment the action is due. Admins can view this queue under Setup by searching for Time-Based Workflow, then filter by rule, object, or scheduled date to see what is pending. When the scheduled moment arrives, the entry is picked up and the action runs. Salesforce groups the actions tied to one trigger into a single batch, and that batch starts executing within one hour after the first action enters it. So the run time is approximate, not to the second. The queue is also the only place you can cancel a pending action. If you no longer want a scheduled field update or email to go out, you delete its entry from the queue. Watching this queue is a normal part of operating workflow rules, because a record can sit in it for weeks before anything visible happens.
The hourly limit on time triggers
Salesforce caps how many time triggers an organization can process in a single hour, and the cap depends on your edition. If more triggers are scheduled in one hour than the edition allows, the extra ones are deferred to the following hour rather than dropped. The classic example: an org with 1,200 triggers due between 4:00 PM and 5:00 PM might see 1,000 of them processed in that window and the remaining 200 pushed into the 5:00 to 6:00 PM hour. This matters when a large data load or a mass update suddenly makes thousands of records qualify at once. The actions still run, but later than you might expect, which can surprise anyone relying on tight timing. Salesforce surfaces an hourly limit warning so admins can react before a backlog builds. There is also a subtle trap with empty triggers. Removing every action from a trigger does not remove the trigger itself, and an empty trigger still sits in the queue and still counts against the hourly limit. To truly clear it, you delete the scheduled entry from the time-based workflow queue.
Reevaluation, edits, and when pending actions get cancelled
A workflow rule's evaluation criteria controls whether time-dependent actions are even allowed. You cannot attach a time trigger to a rule set to evaluate "created, and every time it's edited." That setting would let a record requeue endlessly, so Salesforce blocks the combination. Time triggers are available for the "created" option and for "created, and any time it's edited to subsequently meet criteria." Once an action is scheduled, later changes to the record can pull it out of the queue. If a record stops meeting the rule's criteria before the scheduled moment, Salesforce removes its pending time-dependent actions. Changing the value in the anchor date field can also reschedule or cancel the action, because the run time is recalculated. This is powerful but easy to misread. A user editing a close date may quietly cancel a reminder that the business expected to send. There is also a structural constraint while actions are pending: if time-based actions already sit in the queue for a rule, you cannot add or remove its time triggers or edit the trigger dates until you first delete those queued actions.
Worked example: a 30-day renewal reminder
Picture a workflow rule on the Opportunity object meant to nudge an owner before a renewal lapses. The rule criteria say Stage equals Closed Won and Type equals Renewal. You add one time trigger set to 30 days before the Renewal Date field. Inside that trigger you place two actions, an email alert to the owner and a field update that flips a Reminder Sent checkbox. The day an opportunity is marked Closed Won with a Renewal Date 90 days out, Salesforce queues both actions for the 60-day mark. You can open the time-based workflow queue and see them waiting. If the owner later pushes the Renewal Date out by a month, Salesforce recalculates and moves the scheduled run to match the new date. If the deal is reopened and no longer Closed Won, both pending actions drop out of the queue entirely. When the 30-day mark finally arrives, the batch runs within the hour, the email goes out, and the checkbox flips. Rebuilding the same logic in Flow uses a scheduled path on a record-triggered flow, which gives you the same timing without the legacy queue.
Why Flow scheduled paths replaced this pattern
Workflow Rules reached end of support on December 31, 2025. Existing rules keep running, and you can still activate, deactivate, and edit them, but Salesforce will not fix bugs in the product. The recommended path forward is Flow Builder. A record-triggered flow can include a scheduled path, which is the direct equivalent of a time trigger. You set the path to run a number of days or hours before or after a date field, then place the delayed actions on that path. Flow gives you more than the old queue did. You get branching logic, the ability to call subflows, richer entry conditions, and a single tool for both immediate and delayed work. For orgs that still have rules with pending time-based actions, the Migrate to Flow tool can convert the rule, though teams should plan and test the cutover because complex orgs take real effort to move. Treat any surviving time-dependent action as technical debt. Document what it does, confirm the anchor field and offset, then rebuild it as a scheduled path before retiring the rule.
Configuring a time trigger on a workflow rule
Time-dependent actions are legacy, so most teams now build this in Flow. If you still maintain an active workflow rule in an existing org, here is how a time trigger and its scheduled action are configured. Confirm the rule's evaluation criteria allows time triggers before you start.
- Open or create the workflow rule
In Setup, go to Workflow Rules under Process Automation, then open an existing rule or create one on your object. Set the rule criteria that decide which records qualify.
- Confirm the evaluation criteria allows scheduling
Time triggers are blocked on rules set to "created, and every time it's edited." Use "created" or "created, and any time it's edited to subsequently meet criteria" instead.
- Add a time trigger
In the Time-Dependent Workflow Actions area, click Add Time Trigger. Enter a number of days or hours, choose Before or After, and pick the date field that anchors the schedule.
- Attach actions to the trigger
Under the new trigger, add the field update, email alert, task, or outbound message you want to run at that moment. Save and activate the rule.
A whole number from 0 to 999 that sets how far from the anchor field the action runs.
Whether the offset counts down to the date field or runs the action after it has passed.
A standard or custom date or date/time field on the object; it must hold a value when the rule fires or no action is queued.
The work the trigger runs: field update, email alert, task, or outbound message, the same action types a workflow rule supports.
- Actions run in a batch within one hour of the scheduled moment, so timing is approximate, not exact.
- Removing all actions from a trigger leaves the empty trigger in the queue; delete it from the time-based workflow queue to clear it.
- If a record stops meeting the rule criteria, or its anchor date changes, pending actions are recalculated or removed automatically.
- You cannot edit or remove time triggers while their actions still sit in the queue; delete the queued actions first.
- Workflow Rules ended support on December 31, 2025; build new scheduled automation as a Flow scheduled path instead.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Time-Dependent Workflow Action.
Hands-on resources to go deeper on Time-Dependent Workflow 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 Time-Dependent Workflow Action?
Q2. What queues them?
Q3. What replaces them?
Discussion
Loading discussion…