CRM 2013 – Managed solution problems with out of sync solutions

Solutions were a fantastic concept added into CRM 2011 allowing CRM developers to easily group their CRM customizations in groups (solutions) and easily move their customizations between CRM organisations.

Solutions in CRM offer the CRM developer great flexibility but which can lead to complex multiple and overlapping solutions mixed with branched/versioned solutions.

or

The CRM developer can use unmanaged solutions 🙂

I have written many blogs on CRM solutions

• CRM 2013 – Understanding Solutions and how they work
• CRM 2011 – Solutions and publisher prefix
• You can’t import a CRM 2011 solution into CRM 2015
• CRM 2011/2013 – Progress of solution import
• CRM 2013 – Exporting your changes in a solution from your CRM 2013 trial

Solutions are great but when they go wrong they are awful and can take lots of time poking around trying to find out the cause of the problem.

I’m sure many CRM developers have had problems trying to import a solution where someone has deleted a field, only to add it again as a different type (covered in SQL error whilst importing solution)

Here are some common errors I have encounted with solutions

Solution import Errors

• CRM 2011 – Solution not importing – Timeout errors
• CRM 2011 – SQL error while importing solution in crm 2011
• CRM2011 OptionSetId Cannot be Changed when Importing Unmanaged Solution
• CRM 2011 – error when importing solution

Solutions brief introduction

If you want to learn about solutions read this blog CRM 2013 – Understanding Solutions and how they work, below is a quick recap

• A solution is a way to manage and deploy groups of customizations.
• Managed solutions are read only and the customizations cannot be modified
• Unmanaged solutions copy the changes into the default solution; the solution container is merely a wrapper to move the customizations between CRM organisations.

One of the major headaches with managed solutions is if you remove a managed solution, it removes all the customizations and the data.  This combined with the customizations being non editable (read only) can lead to many frustrating situations which the CRM developer has to work round because they cannot uninstall and install a CRM solution due to the loss of data.

Why use managed solutions

Choosing your solution strategy is an important and scary decision because it can be difficult to swap back from a managed solution to an unmanaged solution.  There is usually some anxiety before you make the decision and push the button and import a managed solution.

There are many choices you have to make in CRM which are very hard to undo like

CRM Entity ownership – How do you decide?

I have talked to many CRM developers who hate managed solutions and only deploy unmanaged solutions. I have been asked numerous times why anyone would use a managed solution, so lets investigate the reasons.

The logic behind a managed solution is two fold

1. Managed solutions are read only to protect the customization creator from users and CRM developers taking and changing the customizations
2. Stopping users from changing the customizations which could result in the customizations not working or working incorrectly.

Managed solutions are great for CRM resellers who created a solution for CRM which acts like a products.  E.g. an Autonumber solution.  They can sell the Autonumber solution, it’s gets deployed and the users can’t change any of the code to stop it working and other CRM developers can look at the code to steal the code/ideas.

This scenario is ideal for managed solutions because if the users change their mind and don’t want to use the solution they can uninstall it and it removes all traces of the solution and its data.

Why doesn’t everyone use unmanaged solutions?

If managed solutions can be problematic why doesn’t everyone use unmanaged solutions?

Unmanaged solutions are great but there are some things to consider

When importing unmanaged solutions, your changes will be written to the default solution.  This will overwrite all

This article Use solutions for your customizations

Never import an unmanaged solution unless you are sure you want to accept all the customizations in it and allow any of those customizations to overwrite any customizations you previously created.

Unmanaged solutions means all customizations are editable, this means users could possibly change a customizations and stop them working as intended by

• Deleting a field
• Add conflicting customizations
• Modifying customizations
• Importing unmanaged solutions could overwrite customer’s modifications or change how they work.

Unmanaged solutions can avoid conflicts but can lead to other problems, often problems caused by overwriting customizations which are not initially obvious.

Managed solutions

Below I discuss some problems CRM developers can experience when using managed solutions.

Multiple managed solutions can be tricky in general

Managed solutions can be problematic is when you have overlapping managed solutions where you have different managed solutions which have the same entity in both.

Managed solutions can have problems when different managed solutions overlap when values and files can overwrite each other and CRM developers being unsure what will happen when one solution is imported over another.

The worst problem can be conflicting problems which cause a manage solution to fail.

Managed solutions out of sync

Managed solutions can be problematic when different versions/phases of the same managed solution are deployed in different environments (e.g. prod, pre prod, dev) with different functionality being delivered.

To visualise this scenario it helps to think of CRM solutions as branches in source control.  Users want changes made to an earlier version but later versions have already been modified.

The CRM developers is in a tricky situation of adding fields/customizations to an older solution but cannot bring these changes to the later branches because it could/would overwrite changes made in the later solution.  This can lead to manually adding fields into the different versions of solutions which can lead to problems

Problems with branched solutions

I recently experienced a problem with branched/versions of solutions which I will explain the problem (I will try, it’s complex), the cause and the solution.

When I use the term branched solution, I am referring to the same solution but with different versions.  I find it easier to visualize and explain the problem if you consider these solutions as code branches.

Resolving conflicts

Any developer who has gone through the process of merging changes through code branches knows it can be a difficult and slow process, involving merging the code, working out if the merged code works and importantly checking the merged code hasn’t broken anything.

When you merge code this can lead to a conflict (this happens when the same piece of code has changed in code being merged) and the developers needs to decide what to replace.

This highlights one of the problems CRM developers have, we don’t do the merging, CRM does and if there is a conflict!  A conflict in customizations

• Plugins
• Workflows
• Web resources (JavaScript)

Conflicts usually involve the imported customization overwriting the current customizations.

Branching solutions problem

I had multiple versions of a solution which was managed

e.g.

• Hosk Solution version 1
• Hosk Solution version 2
• Hosk Solution version 3

• Hosk solution version 1 deployed in production/Live
• Hosk solution version 2 deployed in pre production
• Hosk solution version 3 deployed in Dev and currently being worked on

The solutions above are the same solution with entities, JavaScript, plugins in.

• HSV1 (Hosk solution version 1) was the current live solution and is not being changed
• HSV2 is in preproduction and being tested with some functionality
• HSV3 the current development functionality

Understanding the solutions and their states is easier if you visualise the separate solutions as a waterfall.

Remember HSV2 was created from HSV1 but is now very different and HSV3 was created from HSV2 but now is very different with lots of new and cool functionality.  I have tried to show this by creating them as different colours and shapes.

A situation can occur where a bug is found in Hosk version 1 – HSV1, the CRM developer must decide which solution the fix should be put in.  This problem needs some extra fields to be added to an entity as well as some code.

Where to put the fix?

We can’t put the fix into the latest version HSV3 because we couldn’t deploy this solution to live until all the customizations were finished and tested.

If we put the change into HSV2 we would then need to put all the customizations and changes into live and the customer hasn’t finished testing the customizations.  We would have a problem where HSV2 and HSV3 are out of sync.

The choice made was to put the fix into HSV1 (production solution), add the fields and code, test it on the HSV1 organisation we have and deploy the fix to live.

We now have a problem because the CRM solutions HSV2 and HSV3 are now out of sync.

There are fields and code in the live CRM system which doesn’t exist in HSV2 and HSV3.

One of the main concerns is the current development might not work when deployed with the changes in HSV1, so we have to sync the environments.

How do you get these changes into HSV2 and HSV3?

The fields were manually added to HSV2 and the code added/merged.

The plan was to export HSV3 as unmanaged.

Import HSV2 into HSV3 and then reimport HSV3 with the previous exported version, this will have added the new fields.

Problems occurred when we tried to import HSV2 managed into HSV1 Managed.  The reason it complained was because of duplicate fields.

We added new fields in HSV1 and HSV2.   These fields have the same schema name but importantly different guids.

CRM doesn’t see the new fields as the same field because they have the same schema name; it sees it as a CRM developer trying to add another field with the same schema name.

Gulp, we now can’t import HSV2 solution into the HSV1 environment!

Managed solutions make this tricky

Managed solutions make things tricky because if you remove a managed solution it takes away all the precious data with it.

One of the reasons we ran into this problem was because we didn’t use any other solutions to move new fields/customizations between the different solutions.

Solving the problem

Created a new organisation with HSV1 unmanaged – the CRM org we will call Operation SYNC

Deleted newly added fields/views/dashboards in HSV2

Export HSV2 unmanaged – call this HSV2 modified

Imported HSV2 modified solution onto HSV1

We now have the customizations with the same guids in HSV2

Merge code customizations

This organisation now could be used for the HSV2 environment (old one had to be trashed)

The same technique was used to get the changes from HSV2 to HSV3.

How to avoid Sync/branching solution problem

The key to the problems I experienced was you need to be aware you have different branched solutions.

If you need to add changes to the earliest solution (e.g. HSV1) you need to have a mechanism to bring these changes through the other branched solutions.  It’s important you bring the SAME changes through the CRM systems otherwise (if you add the fields manually) you will be get duplicate errors.

The solution we used above seems easy when you read it but it took a whole day of creating organisations, importing solutions and we weren’t sure it was going to work (fingers and legs were crossed) until it worked.

If the solution didn’t work we hadn’t considered the alternatives but none of them would have been very pleasant, which is why we put of making any further plans.

The first step to avoiding this scenario is don’t create duplicate fields in different branched solutions.  This will lead to duplicate fields and cause solution importing problems.

Ideally it’s better to add new fields in the latest solution; you wouldn’t have to worry about syncing your solutions.

Sometimes this isn’t an available choice because the customer needs a resolve a bug in the production solution.

If need to make a change to an older version you need to view your solutions like a water fall and make sure the changes flows down through all the solutions to ensure the fields have the same guids in all your solutions and as good CRM developers know we should never create duplicate customizations.

You could create a patch solution and import it to your branched solutions but you will need to export/import.

Say you want to add new field called HoskField

• Export current branch – HoskField doesn’t exist
• Import patch solution – Hoskfield added, other entity customizations are older
• Import current branch – Refresh entity customizations, HoskField exists

The most important message in this blog post is for people know the danger of branched CRM managed solutions and the potential problems.