Understanding Solution Cloning feature in detail in Dynamics CRM 2016

In my previous posts, I explained in detail two new features of CRM 2016, solution segmentation and solution patching. To view the posts you can refer to the below links.

Solution Segmentation – https://debajmecrm.com/2015/12/22/understanding-solution-segmentation-in-detail-in-dynamics-crm-2016-create-a-solution-with-just-what-you-need/

Solution Patching – https://debajmecrm.com/2015/12/23/simplify-your-deployment-with-the-new-solution-patching-feature-in-dynamics-crm-2016/

In this article, I will cover in depth another new feature introduced in the CRM 2016 which in Solution Cloning. To understand solution cloning, an idea of solution segmentation and solution patching is absolute necessity. So in case you are new to the concept of solution patching, I would suggest you go through the above posts before continuing with this blog post.

Well, too much of suggestions I guess. Smile So before you get bored lets jump straight to the topic of solution cloning.

For this demo, I have created a solution ‘Solution A’ with the account entity. The following are the components which I added for the account entity.

  • Main Form
  • Active Accounts (Public default view)
  • Fields
    • donotemail
    • donotfax.



Now I go ahead and create a patch for the solution A. In the patch I add an additional field ‘description’.



Now I go ahead and clone the base solution that is ‘Solution A’. Remember that CRM allows cloning of base solution only and not the patch solution. Once you select the base solution and click on ‘Clone Solution’, you are presented with a dialog to choose the version number.


Remember that in solution patching, you are only allowed to change the build and revision numbers of the version number of solution. However since you are cloning a solution, you are basically creating a new base solution from the previous base solution. So here build and revision numbers are non-editable. However you can change the major and minor versions.

I keep the same numbers for major and minor versions. And then click on Save.

The fun part comes here. The moment you click on Save, a new solution with the version number mentioned is created. However the base solution – Solution A and all its patches are deleted. And all the components of the base solution as well as the patches are merged in the main solution.


I added the field ‘donotemail’ and ‘donotfax’ in the base Solution A and the field ‘description’ in the patch of solution A. The new cloned solution has all the three fields.

If you see the description of of the newly created solution, it clearly states – ‘Upgrade of solution A’.


Please remember that when you clone solution, the base solution and all its related patches would be deleted and would be merged into a single solution. So if you intend to keep on the patches, you have to keep this in mind.

I was honestly hoping that once we click on the Save on the clone dialog, it would explicitly mention that all patches of the base solution along with the base solution would be deleted.

Hope this helps!

Simplify your deployment with the new Solution Patching feature in Dynamics CRM 2016.

In my earlier blog post, I have explained in detail the solution segmentation feature in Microsoft Dynamics. In you are new to the solution segmentation feature, please refer to the blog post – https://debajmecrm.com/2015/12/22/understanding-solution-segmentation-in-detail-in-dynamics-crm-2016-create-a-solution-with-just-what-you-need/

In this post, I will cover in as much depth as I could explore Smile, the new feature of Solution Patching in Dynamics CRM 2016. A really innovative solution to all your versioning problems and solution management for your CRM deployment. So without wasting much time, I will jump straight into the topic.

Before understanding the what part of it, let us first understand the why part of it. So when do we need a solution patch? Well say you made a pretty significant deployment and enjoying glass of beer with you team. And before you come out of the hangover, customer points that some stuff is not working and an urgent fix is needed. Wondering how this part of testing got missed even after so much comprehensive testing. Well don’t worry, these happens in all projects.

So what immediately comes to your mind. A patch or a hotfix right? Yes that’s what would come to my mind at-least. To take an example, say you gave the length of a field as 300 characters but some application is feeding data into CRM with more than 300 characters in the field. So if you need a hot fix, you would ideally want a solution with just the field with the modified length. Segmentation in CRM allows you to do that which I have explained in the blog post link above.

Since this hotfix is related to the major development. So when you export the hotfix as managed solution and import it into the target environment, you would need it to apply just on top of the main solution. In other words your hotfix is tied to a basic solution. This is what Solution Patching allows you to do. And remember this point. It is very important and I will come back again to this. So marking this in red.

I have a solution in my environment, called “segmentation demo”. This is the same solution I would use for this post.

Inside the solution, I have two entities “Account” & “Contact” and account entity have two field “name” and “numberofemployees”.



I go the solutions grid, select this solution and click on ‘Clone a Patch’ button on the menu.



The first thing that comes to notice is the Version Number. All of us know, but to just bring the context a version number is usually of the format <major>.<minor>.<build>.<revision>

As you can see, since this is a patch, you are only allowed to edit the build and revision numbers. Wonderful isn’t it? All this time I have been harping that version numbers doesn’t make much sense in CRM and this time Microsoft has just shut me up and made me crawl in the corner Smile. I keep the format provided and click on Save. CRM creates a new solution with the same display name but a different unique name.


So as I explained before, the patch solution is now connected to the base solution which is Segmentation Demo.

Say I just want to patch a fix in the “description” field of the Contact entity. So I just add the field in the entity.

Lets go a little bit deep here. Let us export the solution and peep into the xml and see how the solution looks like. Remember we are more interested in how the solution.xml file looks this time rather than customizations.xml


Looking at the XML, it is very easy to understand how CRM maintains a link between the base solution and the managed patch.

Remember in the beginning, I told I would be back with the concept of how managed patch is applied. You can see I am a man of my words and here I am back Smile.

Prior to CRM 2016, managed solutions are imported on the top of managed stack. Say for example you have a imported three managed solutions i) Solution A ii) Solution B and iii) Solution C. See for the screenshot below. The order of import is from bottom to top as indicated by the arrow.


The final outcome would be that the description field would be of 2000 characters.

Managed patches work differently. That is managed patches are not applied at the top of the managed stack. Rather they are applied at the top of the corresponding base solution. Suppose in the previous screenshot, you need to create a patch for solution B and deploy it. Prior to CRM 2016, it would apply on top of solution C. However a managed patch for Solution B, would apply on top of solution B, it would sit between B and C.


The arrow above indicates the way the managed stack is applied irrespective of the order of import.

I know by this time, you must be wondering about all the advantages and disadvantages of this and personally I can jolt down points both in favour of and against. This post is more related to make you understand the concepts so that you are best judge to decide when to apply patches and when to go ahead with new solutions.

In my next topic, I have covered in detail the solution cloning.


Happy holidays to you all and keep exploring the wonderful CRM 2016.

Understanding Solution Segmentation in detail in Dynamics CRM 2016 –Create a solution with just what you need.

I have been exploring Dynamics CRM 2016 lately and what a wonderful release it has been. Today I was exploring in depth the new solution enhancements introduced with Dynamics CRM 2016 and I have to say I am mesmerized by it. Whatever complaints my customers has been raising regarding solution versioning and management, I think this will address everything.

I will try to explain the solution enhancements in as detail as possible, in series of blog posts. In this post I will discuss on the new feature called Segmentation in Dynamics CRM solutions. So without wasting much time lets jump to the topic.

All this time we wanted to include only the changes you did for an entity in your solution but could never do that. Say you added a new field to the account entity and customized one of the existing fields. Now till 2015 you have to import the Account entity in the target environment. The problem with that is when you add the account entity, all the fields, forms, relationships, keys, hierarchies and what not are imported, although my target was just to import the changes to the two fields.

Well in CRM 2016 you could just do that. Suppose you have made changes to the numberofemployees field and the name field of the account entity. I have created a new solution named ‘Segmentation Demo’. I add ‘Account’ entity to the solution.

The fun starts here. As soon as I select the account entity, I get the below screen.


Just dumbstruck if you are seeing this for the first time? Well I was. You can navigate through each of the tabs and just select the components you have changed. So in my case, I just navigate to the Fields section and select the two fields I require.





Great. Isn’t it?

Let’s get a bit deeper here. Let’s export the solution and explore it’s contents. If I unzip the solution file and open the customizations.xml file, then this is what you see.


Neat. A trimmed XML with just your changes. How much time it would save now for the solutions with multiple entities in it? Immense is the answer.

What if there is something you need to add on to the existing solution. Just click on the ‘Add SubComponents’ and the same window would popup where you can select the components you need.



Have I missed something? Oh Yes. And a very important one. When you add an entity to the solution or you try to add a subcomponent to an existing entity, there is a checkbox called ‘Include Entity Metadata’


What happens if you uncheck this checkbox. Well in the videos and release preview blogs I went through, no-where it is explained what exactly happens if you uncheck this box. So I decided to explore it myself.

With this checbox checked, I exported the solution and this is what my contact entity xml looks like in the customization.xml file.


As you can see, you have entire metadata listed.

Now I uncheck the checkbox, save & publish. Then export the solution. And this is how the customizations.xml file looks now.


As you can see, none of the metadata elements for the contact entity are in the xml file.

In my next article,  I have covered Solution Patching feature of CRM2016. To view the blog post click the link.


Till then, happy exploring CRM 2016.

Dynamics CRM 2016 – Using SetProcessRequest message to update your Business Process programmatically

Exploring new stuffs in Dynamics CRM 2016 is great and if it is something technical and gives me an opportunity to write some code, it’s like icing on the cake for me.

CRM 2016 has introduced the new SetProcessRequest message which enables you to set the business process of a target entity. So let’s get into some action here.

I will demo this with the opportunity entity. The opportunity entity has a default process of “Opportunity Sales Process”. Below is the opportunity record loaded with the same business process.



So I created another business process flow for the opportunity entity called “Opportunity Business Process Flow” I will switch the business process of the record for the above record to this new process.

var service = GetService();

            SetProcessRequest req = new SetProcessRequest();
            req.Target = new EntityReference("opportunity",Guid.Parse("7059510E-59A3-E511-80E4-3863BB35AD90"));
            req.NewProcess = new EntityReference("process", Guid.Parse("AEC906DF-5C10-490D-8D0E-E5620FAAE614"));

            var resp = service.Execute(req);


So once we open the record again, the new process is loaded.



So what about the workflows or plugins registered on change of processid of your application? SetProcessRequest will fire the update message and any workflows registered on change of processid would trigger.

Happy exploring CRM 2016.