Do time-dependent workflows verify the rule criteria is still true before executing?

Question

I have a time-dependent workflow on a custom object called ObjA__c that has a lookup to another custom object called ObjB__c. The rule criteria on the workflow is:

ObjA__c.intVal__c = 5 && ObjB__c.intVal__c = 3

The time-dependent workflow action is set to run 1 hour after rule trigger date.

When an ObjA__c record that has an intVal__c != 5 and which is linked to a ObjB__c where the ObjB__c.intVal__c = 3 has it's intVal__c field update to equal 5 the time-dependent workflow is queued to execute in an hour.

What happens if before the queued workflow executes the ObjB__c.intVal__c is updated to not equal 3?

Since the record being updated is not an ObjA__c record I know that before the execution of the time-dependent workflow the record wouldn't get removed from the queue. However I am wondering if before executing the action if a check is run to see that (ObjA__c.intVal__c = 5 && ObjB__c.intVal__c = 3) is still true before executing the queued action.

---

Edit:

The time-dependent workflow action that this rule executes is a field update.

Answer 1

The criteria is not checked again in this situation - see below

According to the Time-Based Workflow FAQ, any record which no longer matches the criteria for a time-based workflow will be removed from the queue. This is vague though and doesn't indicate whether a test is performed if the other record is updated.

I would expect that the criteria would work like a formula field, and that the system would at least check for validity when the timer elapses before executing anything, discarding the record in the process - but it seems like I am wrong.

Test Results

I ran a test to see if the criteria would be evaluated again before the workflow actions took place, and it seems like no check is performed.

When changing a field on the second object such that the criteria would not be met, the first record stayed in the queue which is to be expected.

However, the field update I specified was still performed once the time-based rule was processed.

Work Around

If you update the record that's queued such that it doesn't meet the criteria for the work flow, it is removed from the queue. An extention of this is that if you modify object B so that A would fail and then perform a non-changing edit on A (i.e. hit edit and then save) it also gets removed on the queue.

The upshot is that you could create a trigger on B after update, to perform a non-changing edit on all child records (object A) of the records being run through the trigger. This should in turn clear out the non-conforming records from the queue and prevent the workflow field updates etc. from taking place.

Answer 2

Work Around: if action is a field update

As Matt mentioned in his answer Time-Dependent workflows only check to see if the criteria is still true if the record that is queued is updated. They do not check to see if the criteria is still true before kicking off the action. However if your action is a field update you could place your criteria in the formula for the field update as well as in the rule criteria. This effectively verifies the criteria is still true before performing the field update.

Using the example from the question and assuming the field update action was setting ObjA__c.updateIntValue__c = 1 the formula value below would not perform the field update if ObjB__c.intVal__c was changed between the time the workflow rule was queue and when it was executed.

IF( ObjA__c.intVal__c = 5 && ObjB__c.intVal__c = 3, 1, ObjA__c.updateIntValue__c )

By rechecking the workflow criteria in the field update you are effectively causing the workflow rule to check if it's criteria is still true before performing the action. Note if the criteria is false you want to set the field value back to its current value.

---

Edit:

Note that in the actual formula value the "ObjA__c." would not appear before the field names. I have included them there only to clarify which object/field is being referenced.

---

2nd Edit:

Work Around: if action is not a field update

Thinking about this solution more it could be combined with another workflow rule if the desired end action was something other then field update.

To do this start by setting up your time-dependent workflow with a field update which updates a field such as wf_trigger__c with a specified value. Then have a second workflow rule that monitors the wf_trigger__c for the specified value with an immediate action that kicks off the desired end action and a field update that removes the specified value from the wf_trigger__c field.