Last week I had a business requirement about executing custom logic but only when the opportunity record goes from “in review” to “approved” status, in any other scenario the logic should not be executed.
So, I was thinking to accomplish this requirement by doing a plugin with a pre and a post image, but then I though what If I can do this with a more “low code” approach, that’s when I remember webhooks.
Before going further, I would like to start by asking what we know about webhooks?
According to the definition from the Microsoft’s documentation, it says that “CRM Webhooks is a lightweight HTTP pattern for connecting Web APIs and services with a publish/subscribe model”
In other words, this means that is a feature which enables us to call an external API or even our own service using HTTP request by linking it to some event that happens in Dataverse like create, update or even the deletion of a record.
Webhooks are present in Dynamics 365 CE world since version 9.0, end of 2017, but I think that they are not used that much, for instance I’ve used this feature a couple of times in real projects since 2019.
But despite of that, there are several posts in the community about how to call an Azure function or a cloud flow using webhooks, but as I said before, what if can do the same thing that I could do within a plugin but using the combination of a cloud flow with a webhook sending the pre and post images to the flow, in the end I wanted to know the pros and cons of using one option over the other.
To start I would like to mention there are two points that we must consider when we want to create a webhook:
Now let’s go with the first point.
If we want to call a cloud flow from a webhook, the flow’s trigger must be http request:
The next action could be a compose action, this is a temporary action for two reasons, one because a flow must have an additional action besides the trigger in order to save it, and also because we want to see what the flow is receiving from webhook.
For now, that is enough for the flow, we will continue later. Now with have to go for the second point that is create the webhook.
For this we have to use the plugin registration tool, it could be either using XRMToolbox or the official one from Microsoft. After we are connected to the environment, we can create a new webhook:
Next, we have to give a name to the webhook, and please allow me to give you a recommendation about this step, add a descriptive name that identify the webhook. And in the URL box we have to put the URL that is available in the flow trigger, so we have to go back to the flow and copy the URL from the trigger:
Before pasting it into Webhook, first paste it into a notepad file or whatever file editor you have because not all of the URL should be in the URL box, the parameters should not be in that part.
And when I say parameters I’m referring to the query parameters, that is to say everything after ? character, in the following example the parameters are api-version, sp, sv and sig:
So, what we have to put in the URL box is what is specified up to the invoke word, and it is also important to mention that we have to replace the %2F characters with the / character in the parameter called sp, at the end that parameter must have this value:
sp=/triggers/manual/run
Also, a good tool to do the last part could be: https://meyerweb.com/eric/tools/dencoder/ just copy and paste the flow URL and this toll will replace all %2F with /
After we’ve finished configuring the Webhook, and before adding the parameters, we have to select the “HttpQueryString” option in the Authentication box. In the end the configuration should be something similar to:
Click in Save button.
Next thing we have to add a Webhook step, just like when we add a step for a plugin:
As I mentioned at the beginning the requirement, I had was to execute a logic only when the opportunity record goes from “in review” to “approved” status, so the step should be in the Update message and the entity should be the opportunity.
It is important to mention that I want the old and new value of the status reason field, so we need to setup a PreImage and a PostImage, and to do that the step must be a PostOperation:
After register the step, the next action is to add the PreImage and PostImage:
First, we register the PreImage and be careful to register only the field or fields that you will need, do not send all the fields because it will make the flow take longer to finish, and in some scenarios, it causes that the Flows trigger twice:
Same for the PostImage, so in the end the webhook configuration should be something similar to:
Now we can make a test updating the status reason of the opportunity within the model driven app: