One of the problems with Dynamics solution development is that there is no change history. Anyone with sufficient permissions can go to Dynamics, add an attribute or update an optionset, and there will be no record of it anywhere.
There are a couple of ways we can deal with that, but let’s have a look at what’s available from the market place first.
There is a change tracking solution for Dynamics 365 provided by Microsoft:
When it was first published, I thought this is it, we got it covered now. Realistically, it probably comes somewhat short of the real change tracking though. The way it works is it’s registering a couple of SDK message processing steps on publish/publishAll:
And, of course, there is a related plugin. All the changes are reported in the Change Tracking entity:
This is helpful, but, unfortunately, this only gives us high-level details of what was published. For example, I just added a new field to the entity, but I can only see that the entity was published in the change tracking:
And we can’t publish an attribute separately, so that’s just about as much information as we can get from the system in such cases.
There is, also, another limitation. When using “Publish All” message is not producing any meaningful results:
Looking at the screenshot above, all I know is a user initiated PublishAll, but what exactly was published as part of that request is not mentioned at all.
Those limitations are discussed in more details in the thread below (more in relation to Publish/PublishAll messages, but that’s what is being used in this solution):
https://stackoverflow.com/questions/39265795/crm-plugin-for-publish-and-publish-all-messages
That said, it may be useful to know that some components were published, and, potentially, get a bit more details about exactly which components were updated.
And alternative option might be to maintain a change log manually. Maybe as a spreadsheet.. or we might create a solution with a couple of entities:
- Change Log
- Change Log Component
So we might use the first entity as a bucket to store details on the individual component updates, and, then, we might store more specific details in the Change Log Component records.
It might look like this:
(You can download that solution from github: https://github.com/ashlega/CRMComparer/blob/master/sourceCode/Solution/ChangeTracking_1_0_0_0.zip)
Now those are all manual options, but, while writing this post, I did recall an old good CRM Comparer tool which keeps showing up on the horizon (and disappearing) from CRM 4 times:
In the original version it might still be helpful, if it still worked, but what if we could integrate it with the solution above?
That’s coming in the next post..