Time Trigger
A time trigger is a setting inside a Salesforce workflow rule that schedules actions to run at a point in time relative to a date or date/time field on the record.
Definition
A time trigger is a setting inside a Salesforce workflow rule that schedules actions to run at a point in time relative to a date or date/time field on the record. You define it in days or hours, before or after that field, such as three days before an opportunity Close Date or one hour after a case is created. When the time arrives and the record still meets the rule criteria, the queued actions fire.
Time triggers belong to Workflow Rules, which are legacy automation. Salesforce ended support for Workflow Rules on December 31, 2025. Existing rules and their time triggers keep running, and you can still edit, activate, or deactivate them, but no new fixes are coming. For new time-based automation, Salesforce points you to scheduled paths in record-triggered flows, and offers the Migrate to Flow tool to convert old rules.
How time triggers schedule deferred workflow actions
Where a time trigger sits in a workflow rule
A workflow rule has two action buckets. Immediate actions run the moment the rule fires. Time-dependent actions wait, and the time trigger is the clock that holds them. You add one or more time triggers to a rule, and each trigger carries its own set of actions like field updates, tasks, or email alerts. The trigger itself is just a schedule. It says how long to wait and which date field to measure from. A single rule can hold several time triggers, so you can stage actions at different offsets from the same date. For example, one trigger at seven days before renewal and another at one day before. Each trigger fires its own batch of actions when its scheduled moment arrives. The actions attached to a time trigger are the same action types you can use as immediate actions. The only difference is timing. This split between immediate and time-dependent work is the whole point of the feature, letting a single rule react now and also follow up later without any manual step.
Defining the offset and the date field
When you create a time trigger, you pick a number, a unit, a direction, and a source field. The number can range from 0 to 999. The unit is days or hours. The direction is before or after. The source is any standard or custom date or date/time field on the object the rule runs against. So you can build a trigger like 3 days after Created Date, or 5 days before Close Date, or 2 hours after a custom Follow Up Date. Salesforce calculates the fire time by taking the field value and applying your offset. If the resulting moment is already in the past when the rule fires, the actions get queued to run within about one hour rather than waiting. The date field is read at the time the rule evaluates the record. If that field is blank, the trigger has nothing to anchor to, so its actions are not scheduled. This is a common reason a follow-up never fires: the date driving it was empty on the record when the rule ran.
The evaluation criteria restriction
You cannot bolt a time trigger onto any workflow rule. The rule must use evaluation criteria of either "created" or "created, and any time it's edited to subsequently meet criteria." The third option, "created, and every time it's edited," is not allowed with time-dependent actions. Salesforce blocks it because re-evaluating on every single edit would constantly re-queue time-dependent actions, which would be chaotic. If you already built a rule with time triggers and then try to switch it to evaluate on every edit, the platform stops you. This restriction shapes how you design the rule. You decide up front whether the follow-up should be set once at creation, or set when the record first crosses into meeting the criteria. That choice changes which records get a scheduled action and when. Plan it deliberately, because changing your mind later means rebuilding the rule rather than flipping a setting.
Org time zone, batching, and the queue
Two behaviors surprise people. First, time-based workflow is evaluated against the organization's time zone, not the time zone of whoever owns or edits the record. A trigger set for a specific hour fires on org time. Second, time-dependent actions are not executed one by one at exact moments. They are grouped into a batch, and that batch starts running within one hour after the first action enters it. So treat the fire time as approximate, not to the second. Pending time triggers live in a monitoring area called the Time-Based Workflow queue, reachable in Setup. From there an admin can see what is scheduled and remove queued actions if needed. There is also a default cap on how many time triggers can be processed per hour in an org, so very large volumes can spread out. One quirk worth knowing: if you remove every action from a time trigger, the empty trigger still stays queued and still counts against that hourly limit until it clears.
When queued actions get cancelled
A scheduled time trigger is not a guarantee. Between the moment the rule queues the actions and the moment they are due to fire, the record can change. If an edit causes the record to no longer meet the workflow rule criteria, Salesforce removes the pending time-dependent actions from the queue. They simply do not run. This is usually the behavior you want. Picture a rule that sends a reminder three days before Close Date only while the opportunity is still open. If someone closes the deal early, the reminder should not go out, and it does not. Deleting the record, or changing the source date field, can likewise reshuffle or drop what was scheduled. The takeaway for admins is that time triggers react to the live state of the record, not a frozen snapshot from when the rule first ran. That makes them powerful for deadline-style automation, but it also means you should test edits and edge cases, because a queued action you were counting on can quietly disappear.
The modern replacement: scheduled paths in Flow
Because Workflow Rules support ended on December 31, 2025, new builds should use scheduled paths in record-triggered flows instead. A scheduled path is the Flow equivalent of a time trigger. You choose a Time Source, which is a date or date/time field on the triggering record, then set an Offset Number and pick days or hours, before or after. That mirrors the old offset model almost exactly. Scheduled paths need the flow to use the "Actions and Related Records" run option, and for update triggers you set entry conditions so a new scheduled path is not created on every edit. Flow gives you more than the old tool did, including better branching, formula logic, and execution-order control through Flow Trigger Explorer. To move existing automation over, Salesforce provides the Migrate to Flow tool, which now supports converting workflow rules that have pending time-based actions into scheduled paths. Run the migration in a sandbox first, then test the timing, since flows and workflow rules can fire at slightly different points.
Add a time-dependent action with a time trigger
Time triggers are configured inside an existing workflow rule. These steps add a time-dependent action to a rule that already exists. For new automation, build a scheduled path in a record-triggered flow instead, but the field concepts below map directly.
- Open the workflow rule
In Setup, go to Workflow Rules and open the rule you want, or create one. Confirm its evaluation criteria is "created" or "created, and any time it's edited to subsequently meet criteria," because the third option blocks time triggers.
- Add a time trigger
In the Time-Dependent Workflow Actions section, choose to add a time trigger. Enter the offset number, pick days or hours, and choose before or after.
- Select the date field
Pick the standard or custom date or date/time field the offset measures from, such as Close Date or Created Date. This field anchors the schedule, so make sure it is reliably populated.
- Attach actions to the trigger
Add the field updates, tasks, email alerts, or outbound messages that should run when the trigger fires. A trigger with no actions still sits in the queue but does nothing useful.
- Activate and monitor
Save and activate the rule. Watch scheduled items in Setup under the Time-Based Workflow queue, where you can review or remove pending actions.
A whole number from 0 to 999 that sets how far from the date field the trigger fires.
The unit applied to the offset number. Hours give tighter timing; days suit deadline reminders.
Direction relative to the source field. Before is for advance warnings; after is for follow-ups.
The standard or custom field whose value the offset is calculated from. A blank value means no action is scheduled.
- You cannot add a time trigger to a rule set to "created, and every time it's edited." Salesforce blocks it.
- Time-based workflow runs on the org time zone, not the running user's, and actions fire in a batch within about one hour of the scheduled moment.
- If a later edit makes the record stop meeting the rule criteria, queued time-dependent actions are removed and never run.
- Removing all actions from a time trigger does not delete the trigger; it stays queued and counts against the hourly time-trigger limit.
Prefer this walkthrough as its own page? How to Time Trigger in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Time Trigger.
Hands-on resources to go deeper on Time Trigger.
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 Trigger in legacy Salesforce Workflow Rules?
Q2. Are Workflow Time Trigger configurations still recommended for new automation work?
Q3. Which modern pattern replaces Workflow Time Triggers for net-new builds?
Discussion
Loading discussion…