Process builder sending multiple mails on production

Question

I have this process, built with process builder, that triggers an Apex class to send a single email, under a condition: that a Case has a specific Status.

In the sandbox, this works perfectly. On production, it aways sends the same mail four times. I haven't found any instances (yet) where it works like it is supposed to.

Process and Apex class are identical on production and in sandbox. What gives?

Edit 1:

In production, the change in Case Status is triggered by a workflow that has a Time-Dependent Workflow Action with a trigger date more than one month in the future. In the sandbox, this is impractical, so there I always edit the Status into the desired value. Just to be sure that the workflow was not the cause, I changed the one month trigger into a one hour trigger. And I observed the same behaviour as in production! For some reason, a change by the workflow triggers the process 4 times, whereas a manual edit only does this once.

And yes, the "Do you want to execute the actions only when specified changes are made to the record?" checkbox is on for the Case Status condition. I "just" have to find out why that seems to be ignored in this case.

The Evaluation Criteria for the workflow are: Evaluate the rule when a record is created, and any time it's edited to subsequently meet criteria and the Rule Criteria is: Case: Status equals 'Some state'

Something else: as well as in production, the process sends 4 mails in the sandbox. Four mails every time. Why not two, three or five?

Edit 2:

4 = 5 - 1. I notice that in the log, the process that (among other things) sends the emails, is going into recursion five times, which is the documented maximum. In its first recursion, it's doing something useful, and in the following 4 recursions it's sending the four mails. Somehow, a change by a workflow causes a recursion 5 deep, but a change by a manual edit doesn't, at least not as deep: just the 2 required 'levels'.

Answer 1

I would check the following:

• Are there any active workflows that trigger additional emails (EDIT: check if that workflow is set to "Re-evaluate Workflow Rules after Field Change")
• Is there a possibility that the same record gets evaluated multiple times (i.e. Process is triggered a second / third / fourth time due to an update inside of the Process)

Answer 2

I haven't used process builder that much, so I could be off the mark, but one thing that can cause problems when Apex interacts with workflows is a subtlety of how the old/new values appear when a workflow field update happens...

From https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm

Trigger.old contains a version of the objects before the specific update that fired the trigger. However, there is an exception. When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger won’t contain the version of the object immediately prior to the workflow update, but the object before the initial update was made. For example, suppose an existing record has a number field with an initial value of 1. A user updates this field to 10, and a workflow rule field update fires and increments it to 11. In the update trigger that fires after the workflow field update, the field value of the object obtained from Trigger.old is the original value of 1, rather than 10, as would typically be the case.

If I were writing Apex to implement the Process Builder setting of "Do you want to execute the actions only when specified changes are made to the record?", then I would be looking at the Trigger.old and Trigger.new. And my code would be deceived into thinking that the Status had changed every time a Workflow field update edited that record.

The only solutions that I have found to this are to use some sort of flag to show that I'd sent the email already; or to stop using workflows and convert the wfs into triggers.

Answer 3

Short answer:

I replaced the workflow by a functionally equivalent process. Because processes continuously get more functionality, this was now possible. No changes to any existing processes were needed, I guess somehow the interaction between workflow and processes caused a problem.

Long answer:

Of course it was not as simple as that. The new process itself is simple: a criteria box and a scheduled action. I made the process recursive (necessary because the order in which the processes are executed is not deterministic) and I checked the “Do you want to execute the actions only when specified changes are made to the record?" box for the criteria. What I observed was that the process was executed twice! The combination of the criteria and the checkbox should have prevented that, but it didn’t. So I made the process non-recursive and then everything worked. This was on the development sandbox. There is no guarantee that it will work the same way on the production org, because - again - the order in which the processes are executed is not deterministic. At the worst, the new process does not get executed at all, because the entry condition is checked at the wrong time. And because it is not recursive, it will only be examined once during a transaction.

Maybe I have found a bug: the “Do you want to execute the actions only when specified changes are made to the record?" checkbox seems to be ignored. At one point, I added a condition to the action itself, but that didn’t make a difference. Then again, maybe all of my processes are way too complex and things go wrong because of that. Still, I have seen entries in the history of the field value changes that were contrary to the process definition.

Edit:

While looking for something else, I came upon This page which states: "To avoid unintended behavior it is recommended to avoid mixing Processes and Workflows on the same Object; Use one or the other."