When “adding required components”, be cautious of the solution layers

You probably know how we can add required components to our solutions – there is an option for that in the maker portal, and it’s easy to use. For example, if I had “contact” table in the solution already, I could add required components for that table:

And the idea is that all the relationships, web resources, etc would be brought into the solution when we use that option. In theory, this is very useful, since, if some of the required components were missing in the target environment, we just would not be able to import our solution there until all those components got included into the solution.

However, depending on the environment, there could be different, and, possibly, unexpected consequences. In my slightly customized environment above, I got 2 more tables added to the solution when I used that option. One of them got added with all subcomponents, probably since it’s a custom table created in the same environment. I also got a few subcomponents from the Account table:

In a different environment, in exactly the same situation, I got a lot more components added to the solution as a result,  and that does not seem to have much to do with where those components were created:

For example, the lookup column below is there now, and we don’t even touch that column in any of our solutions – it is there out of the box, and it’s part of the Field Service:

And that is where one potential problem with “add required components” seems to show up. Once this kind of solution is imported into the downstream environment (as a managed solution), we’ll be getting an additional layer for the subcomponents that had been included into the solution as a result of “adding required components”, and it might not be what we meant to do. Since, if those components are supposed to be updated through other solutions, too, this new layer might prevent changes applied through those other solutions from surfacing in the target environment since the layers would now look like this:

• New solution with required components that now includes Column A
• Original solution that introduced Column A

If we try deploying updated version of the original solution to update Column A, those changes would still be in the same original layer where Column A was introduced, which means we’ll be somewhat stuck there.

And this is, actually, exactly what the docs are talking about:

https://docs.microsoft.com/en-us/power-platform/alm/organize-solutions

So, I guess, beware of the side effects.