In a previous post, I listed the dos and don’ts related to Power Platform ALM. Recently, I’ve been cleaning up environments for customers. At one point, I was faced with no fewer than 420 solution dependencies when I wanted to remove a third-party solution. Then you just love (work) life, right?! Turns out, it was not as bad as it seemed. I hope this post can inspire someone to clean up their environments too.
As the unofficial HTTP response status code says 420 – Enhance your calm. That’s exactly what’s needed when faced with an error message telling you there are 420 dependency issues to solve! Mixed third-party solution components and your own, wonderfully tied together. Better put the Sherlock hat on and dig into the details if you want to succeed in deleting that solution!
Solution Component Dependencies exist in order to prevent you from unintentionally break the functionality of your solutions. You might not be able to:
Avoid dependency issues by:
Third-party solutions might let you reduce the development time/costs. But if you later don’t need it, clean up your environments. You’ll might free up space (it’s a cost too!) and you’ll make your solutions more maintainable in the long run. Uninstalling a third-party solution can be as simple as clicking a button, just press “Delete” and you’re done. It can also be more complex.
Complexity arise if you’ve built your own solutions ON TOP of a third-party solution. Then you’ll have dependencies to handle. Every case will be different, even if it’s the same third-party solution, depending HOW MUCH you’ve built on top of it and your ALM strategy. In my example, all solutions, except for the third-party, were unmanaged, even in target environments. Not according best practice.
Sorry to tell you – there’s no such thing as a shortcut. You can try to open a Microsoft ticket, but that’s more if you get stuck in any of the details narrowing down the list of dependencies. Actions for complex cases with lots of dependencies:
Depending on the complexity of the customizations built on top of the third-party solution, if not too complex – it’s fine to uninstall in the real environments directly. Changes to be done in DEV and deployed correctly of course. If you do not want to mess with your real environments or just “see how hard it would be” and how much it would effect your current solution – safe space environments might be a good idea.
In some cases, it might be worthwhile to consider starting fresh in new environments rather than attempting to clean up existing ones. If there’s a large amount of technical debt and lots of the current customizations and code are no longer in use or needed, it could be a better alternative to start with a blank slate.
You can always create an additional environment and start there, just to see if your process holds all the way. Then you can document the steps you take and when you reach success, you can do the same steps all over again but in the real environment.
In Maker Portal, navigate to Solutions, Managed, choose the solution you want to uninstall and select … Show dependencies.
So for this solution I got 420 dependencies in my list. Can that scare you away? For sure! But try looking at it one dependency type at a time. If you can solve one type, the rest of the same will go smooth. Solving one might narrow down the list with more than one, stay persistent, don’t loose hope.
Looking at the type of issues I noticed the following: It was mostly processes (classic workflows) in the list. Types could be broken down into the following parts using third-party components:
First figure out overall if the customizations causing the dependencies are still in use or not. In my case all the processes (custom workflows) were not, all could be deleted entirely. Dependency types and how to solve them:
When I only had the site map dependency left I had almost made it, almost! Those were a bit tricky. In the list of dependencies, there was complaint about a web resource (icon) that was used. The first were easy to find. I could probably have used the modern app designer, but I did it in the legacy Site map designer.
I located where the icons were used and switched to another OOB icon. (You’ll of course need to verify and make adjustments to it when you’ve deleted the third-party solution, this was a temporarily work-around to get rid of the third-party solution).
But then there were three dependencies left and I could not find them in the UI in the legacy site map! (Perhaps I should’ve been in the modern way of working ).
I then made a new temporarily solution, added one of the sitemaps, exported it, extracted the files and opened the customization.xml file. I searched for the name of the the web resource. And then I could figure out where it was used. Removing the whole group from the site map did the trick.
This was the last dependency, tricky to find in the site map:
Object type Web Resource and Dependent type Site Map.
Looking at the cutomization.xml file I could locate where to find it in the sitemap, open the sitemap and remove that part entirely. (Different approach than for the other parts of the sitemap, where I’d just switched to another icon).
I could then remove the whole Group.
Then finally! No dependencies left to solve!
Then I could delete the third-party solution. Yay! Happy (work) life again! The deletion process took around 2 hours, from selecting the delete button to having it deleted, but good thing it works in the background, no need to sit and stare at it!
I hope this post can inspire someone to dare to clean up their environments and not being scared away by the number of solution dependencies! Just enhance your calm and take it step by step, you’ll do fine.
Featured photo by Carl Newton on Unsplash
Original Post https://carinaclaesson.com/2025/03/05/power-platform-alm-solution-dependencies-enhance-your-calm/