A client called the other day to report that they were suddenly receiving duplicate emails generated by a number of workflow processes. Upon inspection, I found that the workflows in question were indeed being executed twice; but only sometimes! The issue occurred ONLY when creating a new record (not on update).
This issue appears under the following conditions:
1) The workflow is triggered to start both when Record is Created or Record Fields Change AND
2) A new record is created that also sets a value for one of the fields identified in the Record Fields Change list.
Now, you might think, sure, that makes sense. I open a new record form, change some values and save. The record IS being created and I DID change some triggering field values. But that's not how CRM operates. From the workflow perspective, CRM does not consider the field values as changed when creating a new record. These are the initial values being set. Thus "Start When Record is Created" is triggered on Create. "Start When Record Fields Change" is triggered on Update. (Note: I did have to check myself on this to make sure I wasn't just losing it!).
Incidentally, the client recently applied Update Rollup 3 for CRM 2013 SP1 (6.1.3.119). I have not seen this issue reported in other comparable system, so I hesitate to use the term bug. Let’s just call it an issue for now.
Meanwhile, I thought it might be interesting to look at the troubleshooting steps involved as well as a workaround for this issue until it is fixed.
Use Case Scenario: A user receives a call from a customer. They open a new Case record and record the information. The Case form includes a checkbox labelled "Send Acknowledgement Email". Checking the box allows the user to have a workflow send a templated email to the customer acknowledging a case has been opened for them.
A workflow is configured to run both when the record is created AND if the "Send Acknowledgement Email" checkbox value changes. This allows the user to send the email at the time the record is created or at a later date by simply checking the box.
When triggered, the workflow checks to ensure the "Send Acknowledgement Email" is checked (Yes) and that the Contact has an email address populated. And if so, it sends the email and notes the date it was sent on the Case. This is a fairly typical use case.
In this case, the user opens a new Case form, checks the box to send the Acknowledgement Email and saves the record. The customer received 2 copies of the email.
The first step in troubleshooting was to open the Workflow Process and look at the Process Sessions to see what was happening. This revealed that the Process did in fact execute twice.
Next I opened each Session record to determine what triggered them. This showed me that one session was triggered by the Creation of the record and the other was triggered by the change in "Send Acknowledgement Email" field.
Next I conducted a couple additional tests:
I created a new case record but left the "Send Acknowledgement Email" unchanged (unchecked). This gave the expected results; one workflow process executed with no email sent.
I updated the case record I just created and set the "Send Acknowledgement Email" to checked. This also gave me the expected results; one workflow process with one email sent.
So it definitely appears that the workflow engine is registering a field value change when creating a new record.
Here is a potential workaround for this issue. I have to warn you, it’s not ideal and requires some work. So let’s hope Microsoft gets this one fixed quickly.
Workaround:
The workaround involves four steps:
1. Make a copy of the workflow.
2. Set one copy to trigger when Record is created.
3. Set the other copy to trigger when Record Fields Change.
4. Add a filter to this 2nd copy so that it only triggers on an update.
You can copy a workflow using the following steps:
Deactivate the workflow. Set the Activate As dropdown to Process Template. Reactivate the workflow.
Create a new workflow process. From the Create Process dialog, give it a distinct name and enter the relevant information however, for Type, select New Process from an Existing Template. Select the template (workflow you just activated as template above) and click ok.
The new workflow will open. Be sure to uncheck Start When Record is Created. You can leave the Start When Record Fields Change box checked and the appropriate fields selected.
Next, highlight the very top condition in your workflow. Click the Insert button and check Before Step.
Then click Add Step and insert a Check Condition. This will add the condition to the top of the workflow.Next add the following condition:
Process Execution Time is Less Than 2 Minutes AFTER the Case Created On
Why the above filter?
On a healthy CRM server, the workflow engine will kick off the workflow process usually within 30 seconds of the triggering event (even if it takes a minute or 2 to secure the resources). Thus if the Process Execution Time is really close to the record Created On time, we are going to assume it was triggered by the record creation.
Conversely, if the Process Execution Time is more than 2 minutes after the Created On time of the record, we will assume it was triggered by an update and allow the workflow to continue.
Now we have the basis for our filter. If the workflow is being executed within 2 minutes after the record was created, we’re going to assume this is triggered by the record creation and stop the workflow.
This will effectively block the rest of the workflow from executing.
Activate this workflow.
Finally (and don’t forget this step!), open the original workflow process. Deactivate the process and reset the Activate As back to Process.
UNCHECK the box to Start When Record Fields Change. Check the box to Start When Record is Created.
Activate the workflow process.
You now have a process for both Create and Update. While this is not a perfect workaround, it will help keep your critical workflows operational with minimal effort. When the issue is resolved, you can simply add the Update criteria back to the original workflow and remove the Update version.
