Limitation of Solution Patch in Dynamics 365

Recently while working with a Solution Patch we came to realize one of its limitation (or feature) which we weren’t aware of.

If we are trying to update a component through the patch, and that particular component has been customized in the target environment ( through default solution in case of managed), the update won’t work on that component.

Let us take a simple example to understand this.

Below we have created a solution with one workflow in it named Test Process.

Now let us export the solution as managed and import it in Test.

Now back in our DEV let us rename the Process and create a patch for it and import it in Test.

We can see the update in the name after applying\importing the patch.

Now let us go back in our DEV and make some update in the name of the process and import it again in the Test.

We have selected the option of overwriting customizations here.

We can see the update in the TEST after importing the patch.

Now comes the interesting part, in the TEST environment, go to Settings – Customizations and rename the Process. Here we have appended “Updated” in its name.

Now let us import the same Patch Solution back in our TEST with Overwrite selected.

Unexpectedly, we do not see any change, the process is unchanged in the TEST even after importing the patch with Overwrite option. We expected it to be renamed to Test Process Patch Version 1 as it was in the patch solution, instead, it has the suffix Updated to it i.e. the changes that we made directly in the TEST through default solution.

The way we can now update it from DEV is to clone our solution there.

Import it to TEST and apply Solution Upgrade.

Below we can see the new version imported into the TEST and as expected the Process renamed to what it was in DEV.

Hope it helps..

Author: Nishant Rana

I love working in and sharing everything about Microsoft.NET technology !

7 thoughts on “Limitation of Solution Patch in Dynamics 365”

  1. I don’t think it is a limitation. When using Patching and Cloning of managed solutions, you have to consider “Top Wins” strategy. The component you are trying to update is “merged” or not. You also have to check where in the stack of solutions your patch is going in. Are there any managed solutions which sits on top of your solution (the one you are creating the patch for) and whether any other solutions which sits on top of your original solution contains the component you are trying to update via patch. Because your patch seems like it is going to sit on the top of the stack of solutions but it will actually just sit on top of the original solution. So if any other managed solution containing component is on top then “Top Wins” and it appears as if your component is not updated.

    Liked by 1 person

Please share your thoughts

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.