Solution dependency: custom tables used in multiple solutions

[carl1to]

Hi community,

I have a problem with dependencies of a custom table that I use in two solutions. I reproduced this problem in the following demo.

Two unmanaged solutions are created within the DEV environment: 

SolutionA: 

- Created table A

SolutionB:

- Created table B

- Added table A as a lookup column to table B

When I try to import SolutionA as managed solution to another environment, I get the following error:

Why is there a dependency to TableB?

How should you resolve this? Of course I could add table B to SolutionA, but this can't be the idea of the solution concept right?

[Jmanriquerios]

Hi @carl1to 

The concept of a solution is to incorporate the components/objects that are part of the development of an application and have an organization of these components, and an evolution of new components and changes to the present components.

Now, your error is due to the fact that, as you indicate, there is a dependency in your source solution on table A and table B, in your new environment that table B does not exist, so you will not be able to deploy your solution since the components are not complete, what you would have to do is deploy the solution that contains table b or incorporate the table in your solution where you have table a

It is an issue of dependencies on the destination, and it is important that you keep this in mind in your developments so that you can have a correct organization of the solutions.

https://learn.microsoft.com/es-es/power-apps/maker/data-platform/solutions-overview

The most important thing is that this is learned with experience, each person can have a booklet but above I leave you the official MSFT documentation

[carl1to]

Thank you for your reply.

As far as I understand now: you should not reuse custom components if you have only 1 single DEV-Environment

If you want to do my scenario (reuse TableA in another solution), you should create SolutionB in a new Environment where you import SolutionA as managed Solution.

Refs: Solution segmentation broken; Forced to use Add Al... - Power Platform Community (microsoft.com)

Missing Dependencies - managed vs unmanaged PART 2 (Microsoft Power Platform and CDS) - NETWORG Blog...

I thought that I understood solutions, but the more I read, the more I realise that this concept is only practical if you use it as "Container to store and transport (ALM) of components for a given featureset (App)" and have the components in these solutions absolutely independent of components of other solutions.

[Jmanriquerios]

Hi @carl1to 

You are mixing concepts a bit

Normally when we develop applications one of the concepts that we must be clear about is that we have to apply ALM whether manual or automated.

If you only have a development environment where end users enter, or where they do testing, that's why I tell you that you must have a clear ALM and it is necessary. Now, if you are testing and getting to know it and you don't need to put it into production, just one environment is enough.

Now what you are saying about the solution, because in the end it is a container of components of your solution and you can have customized components without any problem. What you must be clear about is that if you have N solutions, when you deploy them to the next environment, the components must be in that target environment, which is why ALM management is essential.

This is what I was telling you in your case, if you have two solutions in dev but in qa you only have one, and table B is part of the solution in dev but not in QA, you will have a dependency problem because when you send the solution for the table A that contains the search view of table B, this table B does not exist in your QA environment and that is why it fails, so either you put table B in the solution where table A is, or you move the solution from table B to the QA environment.

[carl1to]

Hi @Jmanriquerios 

I understand the point about the dependency and that they have to be resolved in an specific environment if you want to import a solution. Either the to solution has no dependencies or the dependent components are already in the environment.

What unsettles me most is that there is no clear recommendation and information from Microsoft about how to deal with this!

The following main options exist (incomplete):

A) Segment in multiple Solutions by feature: base-solution and application-solution

- needs another environment for the base-solution (base-solution is imported as managed in application-dev)

- probably a lot of work to split the current productive solution into base and application.

B) Segment in multiple solutions by component type: tables, flows, apps...

- ALM: automatic ALM with DevOps Pipelines? Atomic deployments?

- easier to split the current solution

Reference Microsoft:

Organize your solutions (Microsoft Dataverse) - Power Platform | Microsoft Learn

other:

Solution Dependencies & Management » The CRM Ninja

Dataverse Solutions explained » Benedikt's Power Platform Blog (benediktbergmann.eu)

Power Platform Solution Management Strategies - Microsoft Dynamics 365 Consultant - Zach Woods (zach...

Master Solution Dependencies like a Boss – Nati Turtledove (nati-turtledove.com)

[Jmanriquerios]

Hi @carl1to 

YES as is, that is why it is important that each organization has its practice in managing ALM based on the best practices recommended by Microsoft and the experience that the team has.

There are different ways but that is something that you will have to discover with the experience that you are going to gain as you work with it.

[rampprakash]

Hi @carl1to 

Please have a look on my video https://www.youtube.com/watch?v=WGPOyoGI-ZI&t=5s

Hope this will help you to solve your solution

Please mark as Answer if it is helpful and provide Kudos

Subscribe : https://www.youtube.com/channel/UCnGNN3hdlKBOr6PXotskNLA
Follow me on Twitter : @rampprakashd
Blog : https://microsoftcrmtechie.blogspot.com