Day 3 at eXtremeCRM 2015 was a day of learning, with breakout sessions filling the agenda from morning to evening. I attended a lot of great sessions with deep dives of features coming in the 2016 release of Microsoft Dynamics CRM, but hands down the session that I was most eager to attend was “2016 Release Deep Dive: Solution Ecosystem Evolution”. I always attend any sessions where the Microsoft Dynamics CRM team presents changes or future plans for the CRM solution framework, mainly because there are a lot of pain points around the existing solution framework that are exacerbated by the at times drastic changes that the Dynamics CRM team at Microsoft reserves the right to make with every release.
Anybody that’s been in one of these sessions knows that they often turn into free-for-all complaining parties for partners and ISVs, but I left this session feeling optimistic about the overall vision for the solution framework. While the changes coming to the solution framework in the 2016 release are some of the largest in any release yet, it seems to me that the product is moving in the right direction by giving ISVs more control over what goes into solutions and how they’re packaged and deployed.
CRM 2016 Release Deep Dive Session: Solution Ecosystem Evolution
Overall, the driving philosophy behind the changes made to the solution framework has been to give more control to ISVs. This applies to the creation and packaging of solutions, and also to the manner in which they’re deployed.
Tight Control of All Solution Components
One of the biggest changes coming to the solution framework in the 2016 release is the ability to granularly select the entity components that will go into a solution. Today, if you add a custom field to the Contact entity and want to include that customization in a solution, the entire Contact entity along with all of its forms, views, charts, fields, relationships, etc. must be included in that solution as well. With the 2016 release, we can now pick and choose the individual subcomponents (forms, views, charts, fields, relationships) we want in the solution without creating possible dependencies or conflicts with system components and other managed solutions. This is a huge improvement to the solution framework from a supportability and upgradeability standpoint, particularly in environments with managed solution stacks.
Patch Solutions
Today, there’s no way to push out a patch for a managed solution that applies ONLY to that solution. That’s because of the way managed solutions are stacked and evaluated in CRM, based on the date they were first imported.
In the existing solution framework, it isn’t possible for me to push out a change that applies only to Managed Solution 1 without making changes to the entire organization. This is because there is no such thing as a “Patch” solution, and any new managed solutions that I import will sit on top of my entire managed solution stack. To make a change to only Managed Solution 1, I would need to re-import the entire solution with all of its components and my desired change.
In the 2016 release, a completely new “Patch” solution type has been introduced. This is a solution package that can only be deployed where its parent solution exists and applies only to that solution. From an architectural standpoint, that means a patch solution will insert itself directly on top of its parent solution in the managed solution stack, not on top of the entire managed solution stack.
This allows us to roll out updates to solutions without having to deploy the entire solution or worry about overwriting or creating conflicts with other managed solutions in a deployment.
Solution Upgrade vs. Update
Today’s solution imports are all “updates”, meaning that the customizations in a solution are all additive in nature and never destructive. Solution customizations cannot be removed through solution imports, only changed or added. While this keeps solution imports relatively safe, at least in the sense that they can’t be destructive, it’s a frustrating limitation for ISVs that want to deprecate a solution component or overcome some conflict in a managed solution environment. Many of you are probably aware of the holding solution method that’s quite popular for getting around this limitation. With the 2016 release comes the new “upgrade” solution deployment option. Upgrading a solution, unlike the existing update, can be both additive and destructive. Essentially, the Microsoft Dynamics CRM team has automated the cumbersome holding solution method with this new upgrade option. This upgrade method also ties into the new patch solution functionality as patch solutions can be merged with their parent solution to create a single upgrade solution package.
This is a really powerful new feature in the solution framework, but it’s being rolled out with some warnings and caveats as the ability to remove components as part of solution import can be dangerous and there are still some behavioral unknowns around this functionality (as with a lot of the functionality around CRM solutions).
Solution-level Dependency Checks
The 2016 release is also rolling out more robust solution-level dependency checks for the solution import process – this means that there will be more upfront validation to make sure there are no broken dependencies at the beginning of the solution import process rather than at the component-level. This will make solution deployment and troubleshooting a much less time-consuming process since we’ll be alerted to dependency issues upfront and will be able to resolve them all at once rather than one at a time.
Looking Ahead
Beyond the upcoming release, the roadmap for the solution framework is considerably more nebulous. The Microsoft Dynamics CRM team has quite clearly stated that each release is working towards a coherent vision that was mapped out long ago with the release of CRM 2011 and the introduction of the new solution framework – they just aren’t ready to share that vision with the rest of us at this point. The only real detail (kind of) that we got was that at some point in the near future, Microsoft will be moving away from the existing XML solution packages – still no word on what they’ll be moving to.
{{cta(‘5fa0776f-1c57-4e06-9e8a-ccfde81d7ab4’)}}