Workflow Queue
A Workflow Queue, also called the time-based workflow queue, is the system holding area in Salesforce that stores time-dependent workflow actions until their scheduled time arrives.
Definition
A Workflow Queue, also called the time-based workflow queue, is the system holding area in Salesforce that stores time-dependent workflow actions until their scheduled time arrives. When a Workflow Rule has a time trigger, the action does not fire when the record is saved. It waits in this queue and runs later, based on a date field plus the offset you defined.
The Workflow Queue is older Salesforce technology. Workflow Rules reached end of support on December 31, 2025, and Salesforce now points everyone to Flow. The newer equivalent is a Schedule-Triggered Flow or a scheduled path inside a record-triggered flow. If you still have Workflow Rules running, this queue is where their pending time-based actions live, and it is where admins go to inspect or clear them.
How the time-based workflow queue actually behaves
What lands in the queue and why
Not every workflow action touches the queue. Immediate actions fire the moment a record meets the rule criteria during a save. Only time-dependent actions, the ones attached to a time trigger, get scheduled and parked here. A time trigger is defined relative to a date or date/time field on the record, with an offset measured in days and hours, either before or after that date. So a rule might say "7 days after Close Date" or "1 hour before a custom Renewal Date." When the record first matches, Salesforce calculates the fire time and drops the action into the queue. The action then sits there, invisible to most users, until the clock reaches that moment. This is what makes time-based workflow feel different from normal automation. There is a gap, sometimes weeks long, between the trigger and the effect. Because the wait can be long, the queue is the only place to see what is genuinely pending. An admin who wants to know "what is scheduled to email this customer next month" has to look here, not in the rule definition. The queue holds the resolved, record-specific instances, while the rule holds only the abstract instruction.
Batching and the one-hour execution window
Time-dependent actions do not each fire at a precise second. Salesforce groups them. When the first action in a batch becomes due, that batch starts executing within one hour. So if you scheduled something for exactly 9:00 AM, it can reasonably run any time up to about 10:00 AM. This is normal platform behavior, not a fault, and it trips up admins who expect to-the-minute accuracy. If a process depends on tight timing, time-based workflow is the wrong tool. The hourly grouping also ties into a governor concept. Each org has an hourly limit on workflow time triggers, and pending actions consume against that capacity. A flood of records all scheduling actions for the same window can push you toward that ceiling, at which point Salesforce defers the overflow to later hours. For most orgs this never becomes visible, but high-volume automation, like a nightly data load that updates thousands of records and each schedules a follow-up, can hit it. Understanding the batch model explains why "my action ran late" is usually expected, and why spreading trigger times out can matter at scale.
Editing rules once actions are already queued
The queue creates a real constraint on changing your automation. If time-based actions for a rule already sit in the queue, Salesforce will not let you freely add or remove time triggers, or change the trigger dates, on that rule. The pending instances are already committed, and the platform protects them. To make those structural edits you first have to clear the affected actions out of the queue. This is one of the most common surprises when admins try to fix a misconfigured rule mid-flight. You change a date field offset, and Salesforce blocks the save because real records are waiting. There is a related trap with empty triggers. Removing every action from a time trigger does not remove the trigger itself. The empty trigger stays scheduled and still counts against your hourly time trigger limit. To actually retire it you delete it from the workflow queue. So good hygiene is not just deleting unwanted actions, it is checking for stranded, empty triggers that quietly consume capacity. Treating the queue as read-only monitoring misses half its purpose. It is also the lever for unblocking edits.
Record deletion and how actions leave the queue
There are three ways a pending action leaves the queue. The cleanest is that its scheduled time arrives and it simply fires. The second is manual removal, where an admin finds the action in Setup and deletes it because it is no longer wanted. The third is record deletion. If you delete the record that owns the pending action, Salesforce removes that record's queued actions too. This matters for data cleanup. Mass-deleting old Opportunities or Cases also quietly cancels any future emails, field updates, or tasks those records had scheduled. That is usually the desired outcome, but it is invisible, so nobody sees the cancellation happen. The reverse problem also exists. Actions can linger in the queue after they no longer make sense, for example when a record's data changed but the already-scheduled action did not re-evaluate. Time-based workflow does not generally re-check criteria at fire time the way you might assume, so an action queued under old conditions can still run. Periodic review catches these orphans. The queue is therefore both a safety net and a place where stale automation hides.
Monitoring through Setup and Event Monitoring
Admins interact with the queue in two ways. The direct way is the Setup page that Salesforce documents as Monitor Pending Workflow Actions. From there you can search the queue, narrowing by criteria so you are not staring at every pending action in the org, then view or delete the entries you care about. This is the hands-on tool for cleanup and for unblocking rule edits. The second way is broader and read-only. Salesforce exposes a Time-Based Workflow event type in the Event Monitoring EventLogFile, part of the platform's auditing data. That log captures queue activity so you can analyze, over time, what time-based actions were added or fired, feeding it into your own monitoring or a security and operations dashboard. The two serve different needs. The Setup monitor is operational and immediate, used to fix a specific problem right now. The Event Monitoring feed is analytical and historical, used to understand patterns or prove what happened. For an org still leaning on time-based workflow, pairing periodic Setup reviews with Event Monitoring gives both the cleanup capability and the audit trail, which becomes important during migrations when you need to confirm nothing important is still scheduled.
Why this is legacy, and what replaces it
Workflow Rules, and with them the time-based workflow queue, are end-of-life. Salesforce stopped supporting Workflow Rules and Process Builder on December 31, 2025. They may keep running, but you get no support and no bug fixes, so new development should not use them. The official successor is Flow. The Migrate to Flow tool converts existing Workflow Rules into flows, and it specifically handles rules that have pending time-based actions, so the queue does not have to be empty for you to move forward. In Flow, the queue concept is replaced by scheduled paths on a record-triggered flow, or by a standalone Schedule-Triggered Flow. A scheduled path lets you say "run this branch a set time after a date field," which is the direct modern equivalent of a time trigger, but with far more power, including conditions re-checked when the path runs and richer actions than classic workflow ever offered. Pending scheduled-path executions are monitored through the flow tooling rather than the old workflow queue page. So the practical advice is plain. Inventory what is still in your workflow queue, migrate the rules behind those entries to Flow, confirm the queue is drained, and retire the rules.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Workflow Queue.
- Monitor Pending Workflow ActionsSalesforce
- Time-Based Workflow Event Type (EventLogFile)Salesforce
Hands-on resources to go deeper on Workflow Queue.
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 the Workflow Queue?
Q2. Where do you find it?
Q3. Can you delete queued actions?
Discussion
Loading discussion…