The new WebApi has some strange behavior when you only update the state code. You would expect that there would be one update to the record, but when you inspect the audit logs, there are two updates to the record. First there’s an update to set the state of the record the the state it already has. The second update to the record changes it to the actual state.
Two updates should only be expected when you update other fields on the record, other than statecode and statuscode. This is not the case. For now I’m curious if this is a bug, or expected behavior.
For a project I’m working on, I change the status of the quote to active through a PATCH call to the WebApi. That worked like a charm. One of the next steps was to create an email when the status of the quote changed to Active. However I got two emails on that record every time I activated it trough the WebApi. First I experimented a bit with different workflow options, but that didn’t solve anything. Next I checked the audit logs and found that there were two updates to the record. The first one setting it to the same state it already had and the second setting it to the desired state.
I was working on a onpremises version of CRM, which I already customized a bit. To be sure I wasn’t due to anything related other than CRM I create a demo tenant in CRM online to try and reproduce the behavior. A bit to my surprise it had the same issue.
Below are two screenshots of the vanilla CRM trial environment. You can clearly see that there are two update to the record in the same minute. And the first update is setting the statecode to the same value it had.
The WebApi PATCH request:
header: Content-Type: application/json
The documentation is on the simplification of updating records. You don’t need to use specific update requests anymore, like SetStateRequest, but a simple update to the record will suffice. It also states that when you update other fields than the statecode and statuscode in one request, two updates will be made on the record. One update for the non status/state fields and one or the status/state fields.
Either this is a bug that needs to be fixed soon, or it’s something we need to work with. If it’s the latter, I seriously need to think about using a workflow to create my emails, as it is impossible to prevent it creating two emails.
My co-worker Marc Gerner ran into the same issue. He created a workaround that solved this issue for him. Please have a look here to see if this helps you out.
Another workaround suggested in this thread is to create a custom field, update that field instead of change the statecode, and trigger a workflow on the change of that field to update the state of the record.
If I understand correctly, Microsoft have fixed the issue and will deploy the solution with version 9. That would probably be the next spring release.