function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Brett WisseBrett Wisse 

Scheduled Actions in Process Builder fire even when criteria is no longer true


I set up a process in process builder to execute fire tasks on a schedule. The process criteria is when a case is created or edited and the individual criteria node is when the status equals "Ready for Call" and does not equal "Closed - Completed". The actions are only executed when the specified actions are made to the record. The schedule is based 0 hours after a formula date field that calculates the next business day.

The scheduled actions work, but when I change the status to "Closed - Completed" the actions are still firing, even though the criteria is not met. This seems to be in contradiction to this documentation from salesforce:

For processes that are set to run when a record is created or edited, scheduled actions remain in the queue only as long as the criteria for those actions are still valid. If a record no longer matches the criteria, Salesforce removes the scheduled actions for that record from the queue.

Am I missing something here? Thanks in advance for the help.


Swapna MistrySwapna Mistry
Hi Brett,

Did you get any resolution to your issue? Im having the same problem. See my post on the community forum:
Brett WisseBrett Wisse
Hi Swapna,

After speaking with Salesforce support we determined that it was process versioning that was causing the problem. For instance, if a case had scheduled actions and I activated a new process and then unmet the criteria, the scheduled actions operating off of the old version of the process do not recognize the new criteria and continue to fire the actions until the end of that criteria node.

In our case, we had tasks that were scheduled to fire. We had to essentially create another process that fires when a task is created and checks if the status of the module related to the task is closed. If it is, that newly created task would be aborted.

So for your  scenario, I'm guessing you activated a new version of the process, and the scheduled actions on the old version are still firing. Pretty unfortunate feature that requires a workaround. How far out do your scheduled actions go?

Swapna MistrySwapna Mistry
Thank you so much. You totally answered my question. 

What an unfortunate limitation of SF.
I just ran into the same issue - due to previous PB versions, tasks are being created when the criteria is no longer met. Brett, could you give a little more detail on how you configured your workaround solution that aborts the task after checking the status of the module? I think I will need to come up with something similar to correct the problem I'm having.
I've also thought about deleting all of the active flows for each record that was queued by that version, but I'm assuming if I do that I would also have to run an update on the affected records to meet the criteria of the correct/current version. That said, without knowing how to determine which records have been affected (and would need to be updated), I like the idea of being able to create another process that can correct the issue instead. 
Thanks in advance for the help!
Brett WisseBrett Wisse
It's been awhile so it's a bit murky, but I remember there were some limitations with Tasks and their relationships to Cases, so we created a field called "Case Status" on the task that got pasted over by a process I believe. Then, we have a process upon task creation that checks if that Case Status field is equal to Closed, and if so it aborts the tasks.

Maricris DarMaricris Dar
Brett would you be able to post screen shots of your secondary processes:  What I hear is that we need to create one process that updates a "Case Status" and then a second process once a task is created to see if the task should be fired? 
Brett WisseBrett Wisse
Hey Maricris,

Yes you're right. I'll attach the one screen shots below. I didn't create another process to update the Case Status, I just built a reference into the scheduled action that was creating the task ("Module Status" - Reference - [Case],Status)

Then when the task is created, if the "Module Status" field on the task is one of our Closed options, it automatically aborts the task so no one really sees it.

User-added image

User-added image
Maricris DarMaricris Dar
Brett can you show me the "Abort Task" logic?  I am able to update the status to the task as something closed, but I still see the task on my completed Activity History. Also, my activity history is ordered by due date so all my future tasks that fired, that I closed in this process, are not only shown, but they are shown at the top of my Activity History list.  (I feel like this is so counterintuitive)
Keith Weaver 8Keith Weaver 8
Has anyone found a solution to this problem.  Our organization found out about this limitation hard way.  We have processes that send drip emails 3, 5, 7 days and they are suppose to stop if the record no longer meets the criteria.  However everytime we make a change to the process the actions are orphaned and the criteria is no longer evaluated.  We have 100s of scheduled actions at any given time so it has created a bit of a mess for us.
Vincent FruchierVincent Fruchier

Same problem here, we have emails supposed to be send as long as a certain checkbox is checked, but the emails seems to be sent even is the checkbox is unchecked..
The process builder is supposed to reevaluate all the criterias before all scheduled actions, I don't know what is happening here !

Help needed !
Nick HungNick Hung
We have similar issue too, and found the root cause in the Salesforce article.
Once a process is deactivated, Salesforce ignores all other changes to associated records.
Considering scheduled emails are common use case, it's very easy to meet this kind of issue when you use Process Builder to design Pending Actions.
This limitataion will make process builder hard to use for scheduled actions.
Tristan Rhodes 6Tristan Rhodes 6
Simple work around:
DO NOT clone or update your process inproduction!!! 
CLone the process in your sandbox, and ensure the new one works as it should.
Export all records that CURRENTLY trigger the scheduled action using data loader from PRODUCTION.
Make the changes to the records so that the scheduled action criteria are no longer met.
Update the records (data loader>update).
Once this is done, up-version your process by using a change set to move the process (which is under the"Flow Definition" component menu), and activate the new version. Ta-Da!

Note 1: If you want some of your existing records to be triggered, the same principal can be used by exporting the relevant records, making a change to the trigger field(s) and saving as a SEPARATE CSV file, updating them (data loader>update), then re-loading (data loader>update) the ORIGINAL CSV file so the records are reverted to their original form. This will then trigger your process node as the changes have been made when the records were mass updated.

Note 2: The slicker way is to use a manually triggered flow instead of data loader if you are comfortable with loops and assignments.
Maria HuemmerMaria Huemmer
If you go to Setup > Flows, you can see all scheduled actions in the "Paused and Waiting Interviews" list. If you know how to find the records, you could delete them manually here. Not a great solution if there are a lot of actions but you can do it.
Melissa Shook 8Melissa Shook 8
Thanks Maria! I knew we could do this with time-base workflows but not Process Builder. 
Phil PernaPhil Perna
Thought - instead of scheduling the actual action (i.e. send email, create task), make the scheduled action a flow or invocable process builder that includes both the criteria check and the actual action. This way if the criteria fails in the future run of the flow or invocable process builder the actual action won't happen.
I've answered this question here ( You can read it for the TL DR; version
Otherwise -
  1. If your organization has matured/unchanging SLA's defined, then Move your Time-Based process nodes into a separate process chain so that they dont get cloned everytime you make changes/introduce new immediate action nodes -OR-
  2. Remove the time-based process nodes and replace with individual time-based workflows instead since they dont have the versioning issue.
Let me know if this helps.
Duncan OgilvieDuncan Ogilvie
Hi Prajvi,

I am having issues with this still.

My Process Builder fires correctly based on criteria that include 'Closed Won' but when this is changed to Closed Lost, the future processes still fire. This is very frustrating.

Would you mind showing a screen shot of how you set up your process chains? Basically I am trying to automate emails 14 days, 7 Days and 2 Days from balance due date but need them to stop sending if the criteria is no longer met.

I feel this should be very simple but Salesforce is not making it very easy.

Faiza YaseenFaiza Yaseen

I am facing same issue with process builder older version.

Can anyone found any solution how i can remove them please suggest? We have 100s of scheduled actions so it has created a bit of a mess for us.