CRM 2013 Solution Import Error – An item with the same key has already been added

In CRM 2013, while importing of solution, we faced the error “An item with the same key has already been added”.

A little bit of searching and we found this very good article which describes how to resolve the error –

However as the link suggests, it was not possible for us to delete the field since we had some data where the field was populated in the target environment. Hence we had to take the alternate route.

We unzipped the customizations and looked for the field in the customizations.xml file.

For e.g. in the screen shot below, we could see the field with physical name “new_IsOpportunityCustomer”. However when we went into the customizations of the target environment the name was “new_isopportunitycustomer”. Clearly there was a difference in casing which led to the below error.

screen 8

To resolve this we changed the physical name in the customizations.xml from “new_IsOpportunityCustomer” to “new_isopportunitycustomer” and re-imported the solution and everything worked fine.

Hope this helps!


{Dynamics CRM} Found More than one RibbonDiff Entity Error- CRM 2013 Solution Import

In CRM 2013, while importing of solution, we faced the above in the Entity Ribbon of the Account Entity.

To resolve the same, we unzipped the customization file that we were importing and then opened the customizations.xml file in a xml editor and checked for the RibbonDiff part for the account entity.

We found duplicate entries in the HideCustomAction. See the screenshot below.

screen 7


We just removed the duplicate entries and the re-imported the solution and it worked again

Hope this helps!

{Dynamics CRM} Default Potential Customer lookup to show only accounts/ Contacts in CRM 2013 Business Process Flows

In the opportunity entity, we have a field “Potential Customer” which is of type “Customer” and it can be both account or contact entity. However sometimes we might need to customize the same to show only contacts or accounts.

For this in the form load of the opportunity entity, just add the two lines of code shown below.

$(“#customerid”).attr(“lookuptypes”, “1”);

$(“#customerid”).find(“img”).attr(“lookuptypes”, “1”);

However in CRM 2013 if we are using business process flows and we include the Potential Customer in the business process flow, the above line of code wouldn’t do the job for you. For that just add the two lines of code shown below.

$(“#header_process_customerid”).attr(“lookuptypes”, “1”);

$(“#header_process_customerid”).find(“img”).attr(“lookuptypes”, “1”);


Hope this helps!

DisableViewPicker not working in CRM 2013

In CRM we are often faced with the requirement of disabling the view picker of a lookup view.

Say we a have a lookup field called customerid on the form of another entity  and on click of the lookup, we need to disable the view selector of the lookup view window.

In Crm 2011 this could be achieved with the following code

$(“#customerid”).attr(“disableviewpicker”, “1”)

However in CRM 2013, you might find the  code above not working as expected. To do the same in CRM 2013, the trick is not find the image of the particular lookup field and  apply the code to the image tag.

$(“#customerid”).find(“img”).attr(“disableviewpicker”, “1”)

Hope this helps!

Change global optionset mapping for a Entity optionset in Microsoft Dynamics CRM without dropping and recreating the field

Recently I came across a situation where my local optionset was pointing to one global optionset and then I needed to point to another global optionset. In CRM to do this, you would have to drop the field and recreate field. But the problem is if you have a running system which is being actively used, you may not be at the luxury of dropping and recreating the fields. Let’s see how we can overcome this situation.

Before continuing, please note that the below procedures is not recommended by Microsoft and interacting directly with CRM Organization database might cause CRM to work incorrectly and following the recommended way is what you should look for.  I would strongly recommend taking a back-up of your customizations and organization database.


I have field “Test Local optionset”  for the contact entity which points to the global optionset “Global Optionset 1”.  Check for the screenshot below. Screen5

But say we need it to map to another Global optionset called “Global Optionset 2”. To do the same, open the CRM Organization database and run the below SQL query on the database.

DECLARE @OptionsetId UniqueIdentifier

SET @OptionsetId = (Select OptionSetId from OptionSet where Name = ‘new_globaloptionset2’)

Update Attribute SET OptionSetId = @OptionsetId WHERE LogicalName = ‘new_testlocaloptionset’ and EntityId = (SELECT top 1 EntityId From Entity where LogicalName = ‘contact’)

After this query is executed, when CRM is re-opened we could see that our Local Optionset set is now pointing to the “Global optionset 2” instead of “Global Optionset 1”



Now there is a question as to what should be with the existing data for the field.  For that a simple console batch to update the previous values with the new values using text matching condition would resolve the problem. This can be easily achieved with CRM SDK Code. Hope this helps! Happy coding.

Change Field data type in MSCRM without dropping and recreating the field

All consultants like me be it in MSCRM or any other technology would surely agree with me – “Change is inevitable”. Every time I implement a project for a client, there is always a huge change in the requirements from the time when we started it and the time when we implemented it. And it has always been my aim to change to accept it gracefully (if not avoid it :)) and then incorporate it in the best possible way for that scenario (might not be the most optimal). Well let’s talk of one such change that I had to recently face in my project.

Before you continue further let me take my accountability off here. Well just joking but on a serious note, please read the lines in bold below. If you don not wish to continue further and if you are not confident of the changes suggested below it’s better you do not do it.

The procedures explained below are not recommended by Microsoft and working on the CRM organization database directly might make your CRM behave incorrectly. Please take a back-up of your database and customizations before you make changes as suggested below.

In my project, we initially created a field as a certain data-type and then all of a sudden we find that due to changing customer requirements, the data type of the field needs to be changed.

Let’s take a simple example below

The field “Test Field” is created as a whole number for the contact entity as show in the screenshot below


Now say all of a sudden, the field data type should be changed so that the user can enter decimal values. However this is not possible from CRM since you cannot change the data type after the field is created. You would need to drop the field and recreate it but in that case you would lose all the data that has been entered for the field.

Oh, thinking of making this change in all your PROD, DEV and QA environments using supported behavior and then planning for data migration for the existing records in production? Yeah, you are thinking in right direction. However if you think that this conventional way is not  fitting the time you have or you want to think otherwise, continue reading.

Lets see how we can tackle this the other way. Let us open the CRM Organization database and check for the field data type in ContactExtensionBase table (for CRM 2013 ContactBase table). When we open the contact extension base table we find that the datatype is integer.


Let us change the data type to decimal with the query below

alter table ContactExtensionBase

alter column new_TestField decimal(23,10)


When we check for the data type it is reflecting as decimal in the database

However when we open the same in CRM, the data type is still reflecting as Whole number.

This is because CRM picks up the data type from another table called AttributeType which has reference to the Attribute table. The code below would change the datatype to decimal in CRM

DECLARE @attributetypeid uniqueidentifier

DECLARE @attributeId uniqueidentifier

SET @attributetypeid = (Select at.AttributeTypeId from AttributeTypes at where at.Description = ‘decimal’)

SET @attributeId = (

SELECT ab.AttributeId FROM Attribute ab where ab.LogicalName = ‘new_TestField’  and ab.EntityId =

( Select top 1 EntityId from Entity where LogicalName = ‘contact’)


Update Attribute

SET AttributeTypeId = @attributetypeid where AttributeId = @attributeId


Now when we open the field in CRM, it is showing the data type as decimal. You may change the Maximum and the minimum value fields as you need and you are done.



Please note that any custom code referring to this field and typecasting it as integer would fail and you need to change the code. Also this would work only if the existing values for the field can be converted to the target data type. For example- for a text field with data which cannot be converted to decimal values, the above script would fail.


Another problem: You had been using local optionsets and suddenly you find that you should use global optionsets. But again thinking of the existing data in Production. Well follow this and use it if you like it.


Hope it helps and saves you some time !