There’s been a significant enhancement to the Dynamics CRM solution framework in the 2016 release. Here’s what the TechNet article on CRM solution segmentation promises us:
To gain tighter control over what you distribute in solutions and solution patches, use solution segmentation. With Microsoft Dynamics CRM solution segmentation, you can export solutions with selected entity assets, such as entity fields, forms, and views, rather than entire entities with all the assets. To create the segmented solutions and patches, you can use the CRM user interface, without writing code.
Sounds pretty cool, doesn’t it? I’m sure there’s hardly a CRM customizer out there who wouldn’t have encountered the challenges with the lack of granularity when it comes to how Dynamics CRM defines some of the solution components to be inseparable from their parent entity. For example, if you just wanted to add a custom chart or modify a system view you always had to include the whole entity into your solution to distribute it from your development environment to other CRM orgs. With this type of “all or nothing” approach, it’s very easy to end up overwriting customizations in the target organization for components that you had no intention of modifying. The worst part really is that you can never be sure if you’ve done some damage after clicking on “publish solution”.
The TechNet article immediately starts talking about concepts like patching and cloning solutions, so it’s important to note here that these really are mostly relevant only to people who ship managed solutions. If you’re an ISV developing an add-on product or work in a large enterprise developer team with automated release processes, this will surely be what you do all day everyday. If, on the other hand, your work is more focused on customizing and configuring Dynamics CRM environments in projects that don’t contain a large amount of custom code and only target a single customer specific production instance, I bet you’re dealing a lot with unmanaged solutions. I know I am, since the price you pay for deploying unmanaged solutions is most often a lot lower than what you’d face when committing to the path of the managed solutions (and crossing that scary point of no return while at it).
What makes the new solution segmentation concept important to understand for any CRM customizer is that each and every one of you will come across it when adding default entities into your solution in CRM 2016 and beyond. After you select an entity like the opportunity, for instance, you’ll be presented with a brand new screen asking you to “select entity assets to include in the solution”:
This is where you now can pick just the components that you wish to ship with your solution once you export it out from the development environment. You could choose just a specific set of fields, for example, or go to the views tab and click the top left corner of the grid to mark all the assets of type “view” to be included in the solution. Want to see how it can be used in practice? Okay, let’s go ahead and pick from the opportunity entity just the Sales Pipeline chart into our solution, so we can modify it.
Let’s say we want to change the pipeline chart to use weighted revenue instead of estimated revenue values. So, where do we get those fields? You create them! CRM doesn’t ship with a weighted revenue field OoB but instead it contains the tools for building it, thanks to the great calculated fields feature introduced in CRM 2015. We’ll therefore need to create a new currency field and set its formula as “estimated revenue * (probability / 100)”. Even though we’re referencing other fields in the formula, there’s no requirement to include them in our solution, as these system fields will be in place in the target environment regardless of our actions. What we might want to pay attention to is something that the solution segmentation engine doesn’t worry about, which is including the system generated “Weighted Revenue (Base)” field into the solution, as that’s where the base currency version of our calculation will be automatically stored. Better safe than sorry! Furthermore, the new solution segmentation model means we can remove any individual component from the solution if we later deem it unnecessary (as shown below).
Now that we’ve got our Weighted Revenue field, we can update the Sales Pipeline chart to use this new value. To test the segmented solutions functionality in more depth, let’s also pick another system component into our package: the Sales Activity Social Dashboard. We’ll update the elements of this dashboard and see how they transfer into the target organization. Once we’re ready, let’s export the solution as an unmanaged package like we’ve always done. We’ll get the warnings on missing dependencies (again, like we always do), but since the whole exercise is about updating just selected pieces of the CRM puzzle, we don’t need to worry about any of those.
Upon importing the solution .zip file into the target org, there are no differences to how things worked with non-segmented solutions. If we want to peek inside solution details before hitting publish, we’re only presented with the high level components, which means there’s no way to tell at this point if the package contains the entire opportunity entity or just a couple of fields from it. If I was importing an ISV solution received from an external source, I would actually like to know what’s included on a very detailed level, but for now we’ll just need to keep on trusting the publisher.
Let’s see what happens to our updated dashboard now. As a starting point I have a CRM Online demo environment from my previous post regarding “preferred vendor solutions” offered by Microsoft. As you can see, one of these solutions (probably FieldOne) has turned the flat CRM 2016 funnel chart into a retro 2011 style 3D version. Yeah, that’s precisely why solution segmentation makes a big difference, as you no longer need to overwrite things just to add new things.
Once we import our new solution and publish the changes, we’ll see that the funnel chart has now been restored to the flat version that we exported from another CRM 2016 org. More importantly, the stages are now different as we’re mapping the opportunities into the pipeline based on our custom field Weighted Revenue instead of Estimated Revenue. The Top Opportunities chart has also been replaced by another custom chart I included into the solution. Looks like our segmentation is working great so far!
Picking the entity assets one by one is perfectly fine for a scenario where you are deploying a very specific change like the one presented here. However, when you aren’t just performing minor tweaks to an existing CRM environment but rather deploying a brand new CRM system for a customer, you’re likely going to be touching a very large number of components. For instance, this week I’ve been working on a deployment project where the current sprint focuses on sales process management functionality. The number of tweaks I’ve done during two straight days of CRM customization is pretty massive, when you start from an out-of-the-box Dynamics CRM environment and turn it into something that actually works the way the users expect. If I would have had to plan in advance which components I need to be touching, or alternatively adding them into the solution one by one as I realize they need to be customized, I would have probably spent ~20 days instead of 2 while waiting for the CRM Online customization dialog windows to open.
What I’m saying is that while having the full granularity of solution components available to you is awesome, there are common scenarios where you actually may want to keep on working the way you’re used to – adding the whole big entity chunk into your solution. Let’s say I’m building a “base customizations” solution package in a development environment which should contain all the core data model and UI customizations for a new CRM org. I know I’ll be messing with the opportunity entity big time, so I want to ensure every change to the OoB configuration is covered. Instead of picking the individual assets, I can tick the box in the top right corner to “add all assets” into the solution at once.
Nice, now I’ve got the best of both worlds! My base customizations package looks like things were before CRM 2016 so I’m comfortable with building the customer specific solution with it. So, with that I’ll conclude my feature overview of a CRM 2016 highlight…
“Wait, hold on just a moment there! Are you telling me there’s not a single “gotcha” discussed in this blog post? This is Surviving CRM! You never do a happy path walkthrough of CRM features without finding some issues in them.” Okay, you got me. I wasn’t really going to stop there. Let’s keep exploring this segmentation path a little deeper, shall we? (more…)
Have you been looking at Microsoft Social Engagement as a solution to integrate social channels with your Dynamics CRM environment, but kept postponing your investments into the MSE application since it didn’t yet allow sending social data physically into CRM? Well, it’s time for a wake up call, since starting from 
