Keeping Dynamics 365 Apps Up to Date

We’re living in the “post-October” era where many of the new Dynamics 365 Customer Engagement features promised in the Oct ’18 Release are materializing into the live environments. Not all of them, though, since that space train carrying the Business Applications release bits has been scheduled to run from October 2018 to March 2019, as you can clearly see: 

While some features arrive in preview and only for a specific geographic region, there is plenty of stuff that’s being deployed to nearly all Dynamics 365 CE online orgs. While we’re not quite yet at the target state of having every customer running the same version of the application, there’s no longer a process for scheduling the update for your own environments on a particular date in the distant future. v9.1 has most likely now been rolled out in all but the most exotic geos.

This lack of CDU calendars to pick the dates from doesn’t mean that everything would automatically get switched to the latest version. Remember that in addition to the underlying platform (now called Common Data Service for Apps, CDS) there are also the actual Apps to update. For example, if you’re running the Sales Hub a.k.a. the Unified Interface app for Dynamics 365 for Sales, the menu items in the App Settings section might look like the following:

Whereas what you should be seeing in the latest version currently is this:

How do we get there? Let’s dive into the world of solutions and find out.

Applying Solution Updates

How do we know which solution versions carry which new features? We don’t have a central place for such information right now, since the Microsoft Dynamics 365 Online releases page only lists fixes and changes to existing functionality (in theory at least). When we browse the documentation for specific features like Playbooks for example, we may see details like this:

OK, that gives us a hint about what versions we should be seeing inside Dynamics 365. Getting the platform version is easy enough via the About menu behind the configuration cog, and everyone who’s customized Dynamics CRM should know where to look for the solution version number.

That leaves us with triggering the actual solution update. As mentioned, these won’t happen automatically, but rather it is the job of the system administrator to install the updates. This isn’t something you do via the standard solutions view inside the application, nor is it available in the shiny and new Power Platform admin center yet. You’ll need to launch the classic Dynamics 365 Administration Center (a.k.a. InstancePicker.aspx). Pick an instance, click on the pen icon next to Solutions and you’ll get a list of what apps from MS or AppSource partners you have available & installed. (Confused about what all these “apps” are? I’ve got a blog article just for you!)

The list will indicate if there’s an upgrade available for some of your apps. Like here we see that the Dynamics 365 Sales Application is offering us the chance to upgrade to 9.0.1810.5012. A complex number, not aligned with the v9.1 platform update, nor with any sort of KB article describing what it actually contains. Oh well, you’ll just need to give it a shot if your really want to gain access to new features like Playbooks.

What’s In An App Anyway?

After running the upgrade process you should see the version number of your solutions change to a newer version. Don’t pay attention to the prominent Installed On column, since that only reflects the very first installation date of a specific solution. However, if you do sort your solutions by this column, you’ll notice that running the aforementioned upgrade process on your Dynamics 365 Sales Application resulted in a brand new solutions being installed, called Playbook App.

Sure, this makes sense since it was one of the Oct ’18 features we’re expecting to find. Guess everything’s not packaged into the same Sales App, just like with other apps like Field Service or Portals that contain a whole bunch of solution modules visible in the list. Let’s go and open up that managed solution to see what’s inside:

Hmm, that’s not a lot. Actually, that’s not nearly enough for adding the whole Playbooks feature into Dynamics 365, since all we have here are navigation components like the App Module and its sitemap. Where are the actual new entities and business logic? If we browse via the Default Solution we can definitely find them, but how did they end up in our org?

The Hidden Life of Solutions

To get to the bottom of it, let’s grab a tool like XrmToolBox and the Solution History plugin developed by Raj. This allows us to browse through the archive of what solution import jobs have been run for a particular org, since every installation leaves a trace in the system. There’s also an extremely handy checkbox for “include hidden/deleted solutions” which we want to enable for our purposes.

The organization in question is a sandbox that I had reset on October 20 and installed some of the first party apps from Microsoft, like Field Service and Sales. I hadn’t touched it before today, October 5th, but based on the Solution History someone definitely has:

That someone is Microsoft. We can see that a couple of days earlier, on a regular Saturday, there have been loads of solution installation jobs run on this very recently deployed org. Some are core components like CustomControlsCore, others are patches to apps I don’t even have installed in this org, like Dynamics 365 for Marketing. Then there’s the msdyn_Playbook solution that apparently has introduced the actual components of the feature into this environment. This probably has made of possible for me to even see the available upgrade for the Dynamics 365 Sales Application, which in turn brought with it the msdyn_Playbook_app solution, finally resulting in the new feature being accessible for the actual end users to play with.

It’s quite enlightening to see the kind of components that get automatically deployed into an online org. One one hand it’s great that there’s such a frequent release train delivering fixes to issues that you might not even had a chance to run into before they’re taken care of by these hidden solution updates. One the other hand, it shows you how little control you actually have over a cloud application platform and its modular first party apps. For developers this is definitely something to pay attention to as a factor in your deployment and testing processes, like András Fördős has described in his blog posts.

There’s been a lot of talk about how this new continuous update policy will introduce new and changed features for Dynamics 365 behind the scenes while still giving the customers the ability to decide when to enable them for the end users. A solution upgrade process like the one described here is of course one method of offering a button that the admins can click on before the visible parts of the Sales application change. As the Power platform and its surrounding admin screens (which there are quite a few already) get unified into a more coherent whole, I’d expect there to be more visibility given to customers about what’s being delivered and how they should prepare to do their part of rolling out application features.