2

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'.

0

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)
|improve this answer|||||
  • No, the email that is being sent is only sent by the process. The process being triggered multiple times could be an explanation, except that the checkbox "Do you want to execute the actions only when specified changes are made to the record?" is on and that I know that exactly the same process is active on production and in the sandbox (I deployed it again yesterday, and saw the problem occur again this morning). – Sander de Jong Mar 23 '16 at 11:23
  • Hi Sander, added some clarification on the workflow "Re-evaluate Workflow Rules after Field Change" – nicolas Mar 23 '16 at 12:18
  • The workflow is set to "Re-evaluate Workflow Rules after Field Change". And I want it to, because there is another workflow that needs to fire after this one. I am now examining the log file that results after the relevant change in Status. It's not easy, trying to find the needle in the haystack. Also: I see that the process is indeed triggered four times, but so far I have not found the clue as to why four times. – Sander de Jong Mar 23 '16 at 12:46
  • 1
    I'd suggest to deactivate the related workflows 1 by 1 to see which one is causing your process to evaluate for 4 times – Marc Zaharescu Mar 23 '16 at 13:58
  • 1
    @SanderdeJong Because a workflow can trigger itself, creating an endless loop. If the workflow changes something to the Case and this change results in the criteria of the workflow to evaluate to true, then the workflow will trigger again. – nicolas Mar 30 '16 at 9:00
0

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.

|improve this answer|||||
  • I guess that it is an interaction between workflow and process builder, but the process builder flag should prevent it. It looks like a bug/feature borderline thing. – Sander de Jong Mar 23 '16 at 14:42
0

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."

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.