Managed Solutions, the NeverEnding Story

How many times have you had a conversation about unmanaged and managed solutions?. If you have worked with Microsoft Dynamics CRM, Dynamics 365 Customer Engagement or Power Apps, probably you have already used solutions and you know what I’m talking about. The key question is: which one should I use? 😵

Managed solutions were introduced with Microsoft Dynamics CRM 2011. It was a great concept but unfortunately, there have been many challenges, which have made many of us carrying on using unmanaged solution.

Many great members of the community have discussed this topic over the years:

Sadly, after ten years, the discussion is still open and very often the same question still remains: which one should I use?.

If you read the Microsoft documentation, it tells you that you should use unmanaged solutions in your development environment and then managed solutions in any other non-development environment where you are exporting the solution to.

Conceptually, it makes sense and I believe it could be a good approach if managed solutions worked as theoretically expected. That is why in our last project (server version 9.1.0000.20453 | client version 1.4.1077-2007.1 | 2020 release wave 1), we decided to give another chance to the managed solutions and we have been using them for our test, staging and production environments. Sadly, our experience has been taught. In less than one year, we have had to raise five cases with Microsoft Premier Support to report and resolve issues caused by managed solutions.

Workflow is not updated

We noticed a workflow was not updated with the latest changes in our test environment. Initially, we thought it could be a problem with the patch as described by Nishant Rana in this article. However, this was not the case. The problem was caused by the default system solution layer in the workflow.

For some reason that we don’t know yet, the default system layer of this component was prioritised over the new one with our changes. We resolved this issue deleting this default layer. Although I don’t have a picture of the actual environment, I have shared below an example from another one, so you can find this option:

Contact entity name doesn’t change

A similar issue happened when we tried to change the contact entity name to “Client”. The new entity name wasn’t reflected in non-development environments. Unfortunately, you cannot delete active layers for the entity component and you need Microsoft’s help.

Unable to change Email entity auditing setting

We tried to enable the auditing in the Email entity in our non-development environments by deploying the managed solution but it didn’t work using the import option “Maintain customizations (recommended)“. To resolve this issue, we had to use the “Overwrite customisations (not recommended)” option.

Notice we had not changed the email entity manually in our target environment previously, so there should have not been any need to use this overwrite option.

Unable to import solution because of dependencies

We needed to delete an existing entity. Using managed solutions, you can delete components from non-development environments, which is a great feature to keep them clean and tidy. However, on this occasion, it didn’t work out. The entity was part of the sitemap and a model-driven app, which is probably the typical scenario. The managed solution didn’t know how to remove these dependencies and then delete the particular entity, so we had to delete the dependencies manually 🧑‍🔧 in order to import the solution.

Error importing SLA records

This was probably the most “entertaining” one. We had to cancel a production release and restore the environment to a previous backup 💥(always remember to take a backup before a release).

The solution was imported correctly, or that was what the first part of the process looked like. The import dialogue said that the import was correctly completed. However, with managed solutions, when you use the “Upgrade (recommended)” option, the import process has two parts: create a new upgrade solution and delete the previous version of the same solution. If your solution is medium or big, you can see both in the solution list during the import process.

In our case, the second part was failing, so that the solution upgrade couldn’t be applied. Normally the solution upgrade is applied automatically by the system, but you can also apply it manually.

We tried both options but none of them worked. We then tried to delete the upgrade solution to leave the system as it was, but a new covert rule (aka Record Creation and Update Rule) was then stopping the deletion as well 😭

“Failed deletion solution. The CovertRuleItem (Id=[GUID]) entity or component has attempted to transition from an invalid state: ComponentStateName: None; ComponentOperation: Delete; ComponentSolutionType: Solution; SolutionOperationContext: Uninstall; IsProtected: True; FinalComponentState: Publish“

At that point, we had an environment where the new solution neither could be installed nor deleted 😣🔫. That is why we restored the backup.

The problem upgrading the solution was with a new SLA record, where we were getting this error message:

“The SLA([GUID]) component cannot be deleted because it is referenced by 1 other components.”

Why a new record needs to be deleted? 🤔

We checked the solution layers for the SLA solution component and we noticed there was a default one! 🕵️‍♂️ We tried to delete it but we couldn’t because the system didn’t allow us to do it. The following message was displayed:

“Unable to remove active customizations. RemoveActiveCustomizations is not supported for components of type SLA.

We also tried to delete the whole SLA record, but we couldn’t because it was part of a managed solution.

Based on the Microsoft support investigation, the default system active layer on the SLA record was the problem (again) 🤦.

The interesting part was that this didn’t happen for another two new SLA records that were also part of the same solution.

Finally, we resolved the issue by importing a new version of the solution without this “problematic” SLA record.

So now what?

What would be my current approach then? What I would do in my new project?.

My heart is still with the idealistic concept of the managed solutions, but my current headache still hurts. It especially hurts when I try to put all this as part of an automated process using Azure DevOps and pipelines where manual intervention shouldn’t be required.

What other problems have you had with managed solutions? Please leave a comment with your stories, I’m looking forward to hearing them.

Feature image by Anna Samoylova on Unsplash