With all those customization options we have in Dynamics, we can do a lot, but, sometimes, it may get a little confusing. For example, we can use worklfows and plugins. Not only that, though.. Both workflows and plugins can be real-time/synchronous or background/asynchronous.
Earlier today I was observing a very interesting behavior. There was a synchronous plugin and there was a real-time workflow in my solution. Actually, I added them to the solution at different times. The plugin had been there long before that workflow was added, so, while adding the workflow, I just assumed that the plugin was working. And it was, but, as it turned out, when there were two of them, the workflow would run first. So, where I was expecting some data to be updated by the plugin before the workflow would start, it was not, actually, happening.
Which contradicts this article:
However, keep in mind that the article above may have been written for CRM 2013, and I was having this issue with CRM 2015.
So, I had to do some digging (and I did it with 365 online)..
As you probably know, we can define Sdk Message Processing Step execution step order when working with the plugin registration utility. Really what it does, it just sets the “rank” attribute of the SdkMessageProcessingStep record:
https://msdn.microsoft.com/en-ca/library/mt622430.aspx
Plugins should not be that different from workflows, so I figured there would be an sdkmessageprocessingstep record for each workflow as well. And, indeed, there is. Actually, if you use Advanced Find, you can see all Sdk Message Processing Steps, including those associated with the workflows.
Unfortunately, we can’t add “rank” attribute to the columns there, and that’s what I really wanted to see.
When it comes to 365, we can use this kind of link to display all those message processing steps:
https://<ORG_URL>/api/data/v8.0/sdkmessageprocessingsteps?$select=createdon,rank&$orderby=createdon%20desc
This will display createdon & rank attributes for the sdk message processing steps, and all those records will be ordered by createdon (the most recent record will show up on top of the list).
Here is what I got for a background workflow:
And here is what I got for a real-time workflow:
Those results were the same for create/update messages.
If you are wondering what’s that 2147483647 rank on the first screenshot, it’s, actually, the biggest integer (int32) number you may have. In other words, you can’t push it any farther in the execution order.
However, when the rank is 0, you can certainly use negative ranks, but, normally, you wouldn’t. So, normally, all those steps having rank 0 will run before anything else.
And, by default, plugin registration tool will set execution order to 1 when adding a new message processing step.
Therefore, to summarize all this, it seems that default workflow/plugin execution order is, actually, different in 2015+ versions:
- Real-time workflows will, normally, run before synchronous plugins
- Background workflows will, normally, run after asynchronous plugins
Are they actually running in the same stage?
I would thing WFs ran in an internal stage, probably 15 or 35/45 depending on pre/post, so there would be no risk of mixing it up with plugin execution.
Have you tried changing the Rank of the WF steps, to control the order of execution?
Another option to control the order is to use the “Synchronous events execution order editor” plugin in XrmToolBox.
Interesting.. Background workflows are using stage 45 (in V9), so I’m guessing they’ll be the last to run then.. Real-time workflows are using stage 20/40 (pre/post) – do not seem to be different from the plugins in that sense