Recently I was investigating removing a component in a production environment, that stubbornly remained. It had me thinking for longer than it should, but after first diving down a couple of rabbit holes, I realised what the issue was. The component was in 2 different solutions and had only been removed from one.

This got me thinking about the implications of components in multiple solutions, doing a few tests and checking the Microsoft docs. Here’s a summary of my findings.

Unmanaged Solutions (Source Environment)

  • When a component exists in both Solution A and Solution B, any changes made to the component in one solution are automatically reflected in the other. This is because the component in both solutions refers to the same underlying instance within the environment. This behavior applies to all solution aware Power Platform components.

  • The default solution within an environment aggregates all Dataverse components. This includes Dataverse components that exist outside of a solution. A Dataverse component is a component that interacts with Dataverse in some way. A Canvas App that is outside of a solution that uses SharePoint as a data source is not a Dataverse component, so isn’t visible in the Default solution. However, add that Canvas App to a solution, or even leave it outside of a solution but add a Dataverse table to the app, means it then becomes a Dataverse component.

  • When a new component is created in solution A, it is not automatically added to solution B. This behaviour is expected and is true even if the new component is a dependency of an existing component in solution B. The new component must be manually added to solution B using the “Add existing” menu – see below.

image of how to add an existing component in the power platform
  • Using the “Advanced > Add required objects” feature for a component, allows you to automatically add to a solution all dependent components. For example, using this feature on a Canvas App in solution B, will add to solution B any dependencies for the app that have been created in solution A.
image of adding dependent components in the power platform
  • As I mentioned earlier, the default solution aggregates all Dataverse components in the environment. If a component exists in multiple solutions, removing it from one solution will not remove it from the environment—it remains in the other solutions and hence the default solution too.

  • To fully remove a component, it must be removed from every solution. Alternatively, it can be deleted from the environment – see below.
image of how to remove or delete a power platform component

Managed Solutions (Target Environment)

  • In a target environment, if a component exists in both Solution A and Solution B, and you remove the component from solution A in the source environment, and then export and import solution A into the target environment, the component will not be removed from the target environment. This is because the component still exists in Solution B.
  • To fully remove a shared component from a target environment, it must be removed from both Solution A and Solution B in the source environment, or deleted from the source environment as described above. Then, both solutions need to be exported and re-imported into the target environment. This ensures the component is completely removed.

Summary

I hope this post is a help if anyone facing similar issues to the one I experienced.

All the above complexity simply reinforces the fact that whenever possible, all components should exist within a single solution!

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top