Unanswered

How do multi-table lookups/polymorphic fields fit in a solution ALM strategy?

(0) Share

Report

Posted on by arpost

455

Greetings, community. I'm trying to plan out an enterprise-scale approach to Power Platform solution development and have a conundrum related to polymorphic lookups. Here's the scenario.

Scenario

I have numerous apps that will have dependencies on some "core" objects (tables, flows, etc.) as well as app-specific objects. I am planning to manage the "Core" objects in a Core Solution that is deployed as a prerequisite in each environment. So when a solution is deployed, the Core solutions are deployed first and then the specific application solutions once they are ready.

Problem

In the case of the image above, I'd like for the AuditLog table to have a polymorphic lookup that interacts with the Form (Sales Solution) and Orders (Finance Solution) tables. If I understand how solutions work, though, this creates a kind of "circular dependency".

If I want to deploy the Core solution, I'd need to deploy the app solutions that contain the tables in the polymorphic.
If, however, I want to deploy, say, the Sales solution, I have to deploy the Core solution first.

Does anyone have suggestions for me or direction on this?

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (4)

Answers (0)

arpost 455 on at

Like (0)

Report

@ScottDurow, I saw you sharing some info related to solutions and ALM elsewhere in the community. Any thoughts?

Was this reply helpful? Yes No
ivan_apps 2,187 Moderator on at

Like (1)

Report

Hello,
you are correct that you’ve added a dependency in your core solution to other solutions so it won’t successfully install.

Your core solution must be able to stand on its own without extra dependencies. What I suggest you do, is remove the audit table from your core solution. Re-add the table to your solution, but do not select all resources to be added, instead exclude your polymorphic lookup column. Exclude or modify your views and forms to also remove that polymorphic lookup. Once excluded from your solution, you should be good to deploy that solution to any other environment as a ‘core’ solution.

once you’ve cleaned up your core solution, you will have to pick which solution goes next. This solution should not have your polymorphic lookup or your audit table. Install it after your core solution.

your final solution should now have the Audit table added but only select the polymorphic lookup column and any views or forms that contain it and add it to the final solution. This should meet all the prerequisites for the solution layering to work. Just remember the order that you install solutions is important.

Was this reply helpful? Yes No
arpost 455 on at

Like (0)

Report

Thanks for the reply, @ivan_apps. Very helpful. Follow up question: how will this approach work if an app solution has a dependency on columns such as the polymorphic lookup in the AuditLog that wouldn't be in the "Core" solution? In my example, both the Sales and Finance solutions would have Power Automate flows and canvas apps that would be using the lookup column in the AuditLog.

So AuditLog is dependent on solutions containing the Sales and Finance tables, but Sales and Finance apps/automation depend on AuditLog fields.

Was this reply helpful? Yes No
ivan_apps 2,187 Moderator on at

Like (0)

Report

Ultimately once you have the initial solutions installed in the right order, subsequent solution upgrades will succeed because all required fields are in the target environment. The initial solution layering is important so that the solutions get installed but afterwards as long as you’re not deleting the audit table or polymorphic lookup it should be good to go.

the trick with the polymorphic lookups is that it needs requires the tables referenced to exist before it installs properly. Same with Flows or canvas apps. Personally to me it seems like you have a very connected system where perhaps it doesn’t make sense to separate the finance and sales apps into separate solutions considering the need to have a custom audit table. Combining the two into a single solution should help to prevent any flows or canvas apps from failing to import due to missing dependencies.

Alternatively, you can modify your Core solution to have a your two base tables ‘Form’ & ‘Orders’. Don’t add any customizations when adding the tables to the solution, rather add what a non-customized new table would contain in terms of views, forms, columns & business rules + table metadata. This should be enough for your Audit polymorphic lookup to be good to go, and any solutions that are installed afterwards are just customizing the ‘base’ table definition. Flows and apps that need referenced to both should then be able to be imported without issue.

hope this helps!

Was this reply helpful? Yes No