There are some really cool integration scenarios and features with CRM but one that I have always liked and also hated a bit is the publishing of events from CRM. There are some ok options for doing this but I tended to find there are some challenges around the who does what bit of the scenario. I will talk a little about a couple of approaches we have used in the past and some of the pros and cons of each.
Using Logic Apps and Webhooks
The first approach is really easy to get up and running with as an integration developer for a single scenario. You can use the dataverse connector and you use the Record Added, Record Modified or Record deleted trigger. This will register the interest with dataverse for an event to be sent when these things happen.
In the below example you can see where I have set a trigger which will fire my Logic App when the accounts entity has a change to the credit limit field. This will help me implement an interface to process credit limit changes for example.
You can see how simple that was. Thats great in many ways but when you tend to do big integration projects you will often end up with loads of Logic Apps registered on different tables in dataverse for different combinations of columns. You can quickly end up with a scenario like below.
In this case one of the good things is that you are easily adding these new logic apps and their triggering and processing but you now have a lot of logic apps with dependencies on a lot of the internals of the dataverse structure and logic. You need to be careful to collaborate closely with your CRM team who may change what the fields are used for or they may change the logic which results in how the rows in the dataverse table are updated and they dont always have a lot of visibility of the dependency externally in the integration platform.
The positives about this approach are the agility and speed to get going. The negatives are the blurred line of separation between the integration solution and the CRM solution which can cause problems later. This risk can be mitigated if you ensure good governance over the overlap between teams.
Using the Service Bus Plugin for CRM
There is an approach which used to be used quite a bit a while back but im not sure ive seen it used much for a while. In CRM you have the plugin registration tool which lets you configure some rules to publish messages to Azure Service Bus based on a change, create, delete events on a table and you can also specify filter columns.
This allows your CRM team to control which events get published and they can be given a few topics to publish to so you can seperate out the messages and in the integration platform you can then implement publish/subscribe patterns to build interfaces on the back of.
Its been a while since Ive seen this approach used much but it is still in the documentation so I assume its still as usable as it used to be.
The positive about this approach is it can give the CRM team control over what is published and when and there are no middle components between CRM and the Service Bus.
The negative ive seen in the past with this approach was that the CRM didnt have a lot of Azure experience so they struggled a bit with the management of the configuration of the plugin registration tool across environments and its relationship to service bus namespaces. Id expect that a few years later this is less of an issue now with most CRM/Power Platform developers being very used to also using Azure.
Using Logic Apps and Webhooks but with a Custom Event Table
One of the approaches we have been using recently which works quite well is to use a custom event table in the dataverse. What we did was give the CRM team control over their own events so that they could create a business event from either a plugin, a workflow or something else in the CRM solution and they would just write an event to a single table which would add to the table the name of the entity the event relates to. The id for the entity row that the event relates to, the name of the event and maybe some other info if needed.
We would then build a Logic App which listens to rows being added to the event table and it will the trigger the Logic App which will create a notification message and publish it to Azure Service Bus. The pattern for this looked like below:
From the service bus we could then trigger many other interfaces easily.
The Logic App which listened for events in the event table looked like below.
The thing we liked about this approach is it allowed for a clearer separation of responsibility between the CRM team and the Integration team. The CRM team would just create a business event and it would trigger integration. The Integration Team could then focus on building interfaces and worry less about the nuances of what logic in the table equated to the business event to trigger the interface.
With this approach we were also able to add to build a replay approach by having a 2nd Listener logic app which listened for updates so we could let the CRM team re-trigger events if they needed to.
What id like to see
Its quite interesting when you look at some of the options available in the different products under the Dynamics and Power Platform eco-system. In CRM/Dataverse there is also an event hub endpoint support which can be used in a similar way to the Service Bus plugin I mentioned above (more info here: https://docs.microsoft.com/en-us/powerapps/developer/data-platform/work-event-data-azure-event-hub-solution).
If you look in the finance and operations area for Dynamics there is also a business events feature and it has support for a number of different options. I know there are differences between these areas of dynamics but the event grid one is a really interesting one to look at (https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/business-events/how-to/how-to-eventgrid).
I think there are really 2 types of use case for these events from Dynamics:
- Table change feed – a crud operation has happened on a table
- Business events – a significant business thing has happened such as order created
Id like to see something like the ability to configure a dataverse to point to an event hub domain and just auto publish change tracking for each table to a topic within the event grid domain that I configure. If it told me which entity changed, its id and the columns that changed then it would be very easy for me to setup filters for the things I am interested in and I then have the full range of destinations for an event grid subscription available. This would simplify the configuration for dataverse by removing the plugin configuration for every entity and queue which is painful. I could just configure the event grid domain once for the Power Platform environment and then it would turn on tables to publish changes a bit like we do for the dataverse synapse link.
For business events which are based on application logic rather than table data changes I think the table approach we have works quite well because its easy for the CRM team to implement but if there were some more out of the box ways to do this then it could also leverage event grid integration for external consumers.
Summary
Anyway this article was just me brain dumping a few ideas about some of the stuff we have done and in the past for CRM events and also some things id like to see to make this pattern event easier. Im watching newcastle united play football at the minute and the match is so bad that I thought I might as well also do something productive. Hope there are some things in here people find useful.
