Workflow: subsequently meet criteria vs ISCHANGED. What is the difference?

Question

When creating a workflow that needs to trigger on specific edits on a record, there are two options:

• Evaluate the rule when a record is created, and every time it's edited
• Evaluate the rule when a record is created, and any time it's edited to subsequently meet criteria

You can only use the ISCHANGED() function with the first variant. Say, I want a workflow to fire when a condition C, involving some_field, becomes true. What is the difference between using the first variant with formula ISCHANGED(some_field) && C and the second variant with formula C (and nothing more)?

I am not interested in time dependent actions, so from that perspective I don't care. I am wondering if there is a difference regarding whether the workflows are fired/evaluated when some_field is changed, because that can have consequences on process flows (which might be triggered or not).

Answer 1

Compile size/complexity vs. granularity. Functionally they're equivalent.

If you must check ISCHANGED in your criteria, it increases compile size. So If you apply it uniformly to several fields, it may be better to just use the "subsequent" option. The flip side is you give up some granularity. For example, maybe changing RecordType shouldn't trigger your rule but changing OwnerId should.

You can also use criteria instead of formula with the "subsequent" option, whereas I don't think there's an Is Changed operator for the workflow builder criteria (though Process Builder has it).

Answer 2

At the risk of thread necromancy, I feel I should make an important addition to this question:

I like Adrian's answer, but one additional point I'd like to add is that with Subsequently Meet Criteria, there's an additional issue you'll have to address: Re-parenting the record.

Let's say you have a workflow on Opportunity that when some checkbox is checked (using Subsequently Meet Criteria), send an email of some sort. Not only would it run when somebody checks the box, but it would also run when the Account is changed on the opp, or when the opp is reassigned to another user.

This is called "re-parenting" - when a lookup to a parent record (Not really just a lookup; actually a Master-Detail but for standard fields this may not be obvious which is which) is changed, it will re-run Subsequently Meet Criteria workflows again as though the conditions in question were brand new (that is, in our example, as if somebody just re-checked the box).

For most standard objects I can think of, the fields that qualify as Master Detail fields for the purposes of this (admittedly odd) functionality is either a standard Account field, the standard Owner field, or any custom Master-Detail fields. In the case of the "Case" standard object, I believe the Contact field is also considered a Master-Detail relationship.

The workaround for this would be to use a "every time the record is created or edited" workflow and use ISCHANGED() to achieve your functionality. Of course, if you have a requirement to use time-based workflow with this, it won't work as it is not supported in this type of workflow. For that, you'd have to use code (I can't recall at the moment if the Process Builder is affected by a similar "functionality" or not)

Answer 3

1. Evaluate the rule when a record is created, and any time it's edited to subsequently meet criteria

Suppose you have pick list field Status with Values as Prospecting, Closed Won and Closed Lost

You have workflow rule which has criteria a Status = Closed Won. This means action for this Workflow will get executed when status field is updated to Closed won from either Prospecting or Closed Lost. So This rule will be true when, Propecting (Old Value) --> Closed Won (new Value) Closed Lost (Old Value) --> Closed Won (New Value)

This work flow will not execute when, Closed Won (Old Value) --> Closed Won (New Value) Because in this case, we are not updating Status field. This is considered in "any time it's edited to subsequently meet criteria"

This will fire any time a record is created, and if edited to meet criteria. So once it fires the rule criteria has to change to something else, then change back to the rule criteria in order to fire again. So if you have the criteria of Active = true, you have to edit the record, change to inactive, save, edit again, and change to active for the rule to trigger.

2. Evaluate the rule when a record is created, and every time it's edited - In this rule the workflow will be executed every time it satisfies the rule criteria. It does not check for Previous Value.