CRM 2016 Solution Segmentation for The Rest of Us

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?

Even though we’re riding in the Wild West with our unmanaged solution deployment strategy, there are situations where we may want to keep our customizations in more than one solution package. A common need arises when we want to configure a business logic that doesn’t deal with just metadata but rather “real data” in the CRM database. The nasty things about data is that each record will have a unique GUID depending on the environment, which means any solution component that references them will effectively break once we deploy it into a different target organization. Without developing automated deployment scripts (or using the Configuration Migration Tool from MS, or better yet, Configuration Data Mover from Lucas Alexander), you’ll need to manually fix these references in the target environment after solution deployment. As a one-off task it ain’t too bad, but if you’d need to go through these after every release into test, QA, production environments, that becomes a real liability.

We’ve previously already been able to keep processes separate from their primary entity, but Business Rules are tied to their master entity. Now with the solution segmentation feature, could we also set the Business Rules free from this slavery and ship them in a whole separate solution, only when there are changes needed? As an example, we might want to leverage the “set default value” action of Business Rules to configure a lookup field with a static reference to another record. Also, we might need to use a condition in a Business Rule that references a particular related entity record. These type of assets would be the perfect candidate to be shipped in a solution of their own, as shown in the example below.

Where’s the catch then? Well, if we’ve gone and built our base customizations solution mentioned earlier by using the strategy to “add all assets”, we may be in for a surprise once we discover that the two new business rules we created have actually been added into the other solution, too. What’s even worse, we don’t seem to have the “remove component” or “add subcomponent” buttons available under this base customizations solution to remove these unwanted assets from here. Which effectively means that our earlier solution dedicated for Business Rules is pretty much useless, since every time we ship the base customizations that includes the opportunity entity we’ll also get the Business Rules included there, together with their static GUID references that will break the target environment. Doh!

Why is this happening then? The explanation is that the “add all assets” button isn’t actually a shortcut for you to quickly select all the components listed in the different tabs when you add an existing entity into your solution. In reality it’s the legacy mode button that will create a non-segmented solution version, just like you would always get with CRM 2015 and earlier versions.

Obviously the “add all assets” button cuts a few corners since using it to add the opportunity entity into a solution only takes 5 seconds, whereas selecting all the assets individually from the tabs makes CRM (Online) hang for 2.5 minutes before you’re shown the dependency notification screen. There’s probably a whole lot more calculations being performed behind the scenes when taking this route. Also the output is different since with the segmented solution route also all the other entities with relationships to the opportunity entity (regarding activities etc.) are automatically included in the solution. Well, to be precise, only the relationship attribute from them is present there, but when working with the same old solution management UI folders this isn’t immediately obvious.

The good news is that you can mix & match the two different methods in a single solution. So, you could have the entire opportunity entity in the solution via the “all your assets are belong to us” option and just a single field, view or business rule for the quote entity, for example. The visibility of the remove/add subcomponent buttons will then vary based on under which entity you are in the solution. If you’re trying to avoid touching components that are being modified in another environment, it is then perfectly feasible to leverage the solution segmentation features also in unmanaged solution scenarios. The componentization of solution assets in CRM 2016 definitely gives us more room for planning our customization strategies, so now it’s a matter of trying them out in real life scenarios and figuring out the best practices for when to segment your CRM solutions – and when not to.