Solution Track— Be aware of Dynamics patches and updates of your instance

“Whenever the people are well-informed, they can be trusted with their own government” — Thomas Jefferson

Microsoft has started to deliver minor but unannounced continuous updates of the Dynamics platform. Although this is for the sake of evolution, they may introduce hidden dependencies, which eventually break otherwise functioning systems or CI pipelines.

Thankfully, starting with version 9, Dynamics is also being delivered and updated with managed solution packages, which are hidden from our eyes!

My goal

I want to track events whenever someone updates a solution in my instance. I want this tracked and stored within a custom entity in the same instance.

Your scenario may differ - send an email, push notification to a slack channel, store the audit trail in Excel — but my solution will be applicable for all these cases too!

My custom entity (Solution Track) has the following fields:

  • Display Name: the display name of the updated solution
  • Event Date: date and time when the event happened
  • Event Type: an option set, which provides future extensibility, but for now always set to “Update”
  • Unique Name: the unique name of the updated solution
  • Version After: the new version of the solution after the event

The solution

Unfortunately, sticking to the “old school” doesn’t help. The supported messages for Solution entity only allow to hitchhike Delete and Retrieve messages for plugin, not the Create or Update.

Digging deeper, checking the not entity related messages, which indicate Solution events (e.g.: ImportSolution, …) we end up with the same result: not available for plugins. Was a good bet because the new Activity Logging uses them, though not really detailed.

Exploring the triggers in MS Flow in more details, we can notice, that both the Create record and Update record triggers are available even with the Solution entity.

So, things to do:

  • Navigate to https://flow.microsoft.com
  • Your Dynamics licence should already provide access, but change if needed
  • Create a new Flow from blank
  • Search for Dynamics triggers, and add “When a record is updated”
  • Sign in, define your organization and the trigger entity (Solution)
  • Add the Dynamics action “Create a new record”, and select your custom entity
  • Apply dynamic content from the trigger to the attributes (e.g.: Unique Name of the solution)
  • Set other attributes (e.g.: for Event Date the utcNow() function)
  • Save your flow, and hit “test”. You have to trigger it by updating one of your solutions as can not test with the internal ones

Result

My Flow was idle for weeks, but at the end of August it started to be busy on one of the Trial instances: my custom entity got populated, as you can see in the first screenshot, so I have queried the back-end too:

One of the many upsides with Flow is, that we can check the Run History. So I did it. During the time I was overseeing my solution, there were two platform updates, which updated some of my internal solutions.

Opening one of the history records I am able to verify, that it run indeed on an internal solution:

Conclusion

Elements of the Microsoft Cloud landscape evolves quickly, so keep experimenting! Things, which were previously not possible, turn out to be simple with the new tools: we can hitchhike Create and Update messages of entities which are not enabled for us in Dynamics!

The solution I have shown here is the bare minimum. Improvement would be to track installation and deletion of Solutions, or send a notification to the system administrator — though the variations are limitless. Also important to note, that a validation step could be useful, as at this state whenever the event is called, we create a new record regardless, whether the solution got updated with a new version.

The two update batches — which I was notified about — were most probably scheduled ones: LINK. That said, these service updates are communicated without dates — as being delivered globally — so with seeing the change of an internal solution I could have triggered a CI build to verify, whether everything is still intact or not!

Reference