web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

News and Announcements icon
Community site session details

Community site session details

Session Id :
Power Platform Community / Forums / Power Apps / Modular Solution ALM a...
Power Apps
Answered

Modular Solution ALM approach with Lookup dependencies

(0) ShareShare
ReportReport
Posted on by 5

I would much appreciate help with the following scenario in PowerApps, with Model Driven Apps, regarding the proper set-up of environments, solutions, and pipelines.

I have the following Environments:
Dev - Type: Development
Test - Type: Production
Project I - Type: Production
Project II - Type: Production
Project III - Type: Production

I wish to develop Solutions as 'building blocks'/'modules', with the following concept:
Solution A, has table A and App A only
Solution B, has table B and App B only
Solution AB, has table AB with a look-up to tables A and B and App AB
Solution C, has table C and App C only,
Solution ABC, has a table ABC with a look-up to tables AB and C and App ABC
Etc.
In reality this approach would go beyond 50 solutions, all, like a tree-structure depending on each other.

Project I needs Solution A and B only
Project II needs Solution A, B and AB only
Project III needs Solution A, B , AB, C and ABC
Etc.

I wish to develop the 'overall' data-model in a single Dev, and do testing in a single Test environment. And from there deploy solutions to separate projects production environments as needed.

I'm using Pipelines.
Pipeline 1: Dev -> Test -> Project I
Is working fine, and I could deploy Solutions 1 by 1, without dependency problems as long as I deploy them in the right sequence. (First A, then B, then AB, etc.)

I have 2 issues.
Problem 1
I can only make Pipelines to Project II and Project III as follows:
Pipeline 2: Dev -> Test -> Project II
Pipeline 3: Dev -> Test -> Project III
This means for every solution I wish to deploy in all 3 projects, the same solution needs to go through Test environment again, increasing its version number.

While I would be looking for:
Pipeline 1: Dev->Test
Pipeline 2: Test->Project I
Pipeline 3: Test->Project II
Pipeline 4: Test->Project III
I cannot do this, because pipelines start in a Dev.

Problem 2
If I send Solution A and Solution B to Test before making Solution AB with the lookup, they do not have a dependency.
But as soon as I make AB.. A and B start becoming dependent. Meaning, I cannot possibly publish them as separate solution anymore.
A and B are depending on AB, and AB is depending on A and B.
Considering the approach I'm trying to get at, it sounds like I will not be able to use 'Modular' or 'building block', as everything becomes depending on everything.

What strategy should I adopt that supports what I'm trying to achieve? 

Thanks in advance!



 

 

Categories:
I have the same question (1)
  • MichaelFP Profile Picture
    1,943 Moderator on at

    In this scenario to remove the dependence between all the solution you must have each solution from a different environment. Doing all in one environment you only will have root layer, and the relationship  it will be required when export the solution that doesn't have the other table.

    I would you recommend to create a core environment that will have all the stuff that will be shared between environments A, B, C. 
    Create another 3 dev environments of A,B and C. And apply your customizations with this organization you'll be able to share componentes  between the environments.

     

    If my answer helped you, please give me a Kudo (👍). If solve your question please mark as solution. This is help the community.

  • Verified answer
    Ami K Profile Picture
    15,687 Super User 2024 Season 1 on at

    @MrJohnHimself - another option is to make your ALM structure component centric as opposed to Solution centric. This means adopting Microsoft's recommendation of using "Segmented Solutions" in your ALM.

     

    If you have a simple app with a couple of tables and a few components, and you can be virtually certain those components will not be depended on by other Solutions, then using a Solution is the recommended option. In addition, if you have an app which uses Flows and those Flows are only associated to that app, then packaging those components into single Solutions is fine as well.

     

    Where trouble can begin, and as you have noticed, is when you have up to 50 Solutions which share the same components in, as you put it, "a tree-structure depending on each other".

     

    For example, suppose Solution A includes a specific component, such a Table, a Flow and a Canvas App. Developer A is making updates to the Entity views and Flows, while Developer B is currently making updates to the Canvas App. If we included all components into a single Solution, we cannot import to Production yet because although the Canvas App is ready to deploy, the Entity View and/or Flow is not. 

     

    One option to address this, and one which I personally use, is to adopt the segmented solutions approach for ALM.

     

    https://learn.microsoft.com/en-us/power-platform/alm/segmented-solutions-alm 

     

    By segmenting the Solution, you only include components that are ready for distribution as an update into the Production Environment. The fundamental purpose of this setup is to avoid cross dependency risks when managing multiple Managed Solutions in the same environment, because as you're aware, cross dependency errors are a nightmare to resolve.

     

    Another problem segmented Solutions can potentially avoid is a scenario where several Solutions contain the same component. For example, Solution A includes a specific component, such as a Security Role. Later, you also have Solution B which also includes the same Security role as a required component. Later, you remove the Security Role from Solution B but receive an “import failed due to missing dependencies” error because Solution A depends on it.

     

    Note however that for this solution to properly work, you will need to:

     

    1. Import your Unmanaged Solutions to your Developer Plan Environment as a holding area and take zip backups

    2. Completely reset your Dev, Test and Prod environments.

    3. Take the Unmanaged Solutions and start splitting out the components into separate Solutions

    4. Import the Segmented Solutions back into your Dev, Test and Prod environments to end up with something like this:

     

    Amik_0-1717898405239.jpeg

     

    Given your doing automated deployments via Pipeline, I should caveat that managing individual components in this way via a segmented Solution creates more work, but it is a very workable option for you.

  • MrJohnHimself Profile Picture
    5 on at

    @Amik , thank you for the very elaborate answer. Much appreciated.
    This is what I ended up doing:

    I have uninstalled all Solutions from Test and Prod environments.
    I have reset the Dev environment.

    I remade Solution A, which has a table A and App A only, and exported as managed solution
    I remade Solution B, which has a table B and App B only, and exported as managed solution
    Then, when I started on Solution AB, I first 'Add existing', and add Table A and Table B, without customizations and without metadata. Just the 'bare' tables. Then I completed this solution by making table AB, which has a look-up to tables A and B and added App AB. Again export as managed solution.

    Instead of using the Pipelines functionality. I imported the managed solutions in Test and Prod for Project I and Prod for Project II. 

    Then, I made modifications (adjusted views, added columns, etc.) to any of the Tables, exported the solutions again as managed. It gets a higher revision number.

    Then, when importing again in Test or Prod I and Prod II as needed, it confirms that I'm planning to do an upgrade on an existing solution. And all works without any dependency errors.

    In short:
    For a Modular solution ALM approach with lookup dependencies: First add the related tables without customizations and metadata to the solution BEFORE making the Lookup.

    For an approach that uses Dev -> Test -> multiple Prod.. use the manual export and import, as the Pipeline approach would require a Test for each Prod.




  • Ami K Profile Picture
    15,687 Super User 2024 Season 1 on at

    @MrJohnHimself - I personally would have excluded App A from Solution A and App B from Solution B, and then made a single Solution which only contains Tables which have have any relationships with one another (Table A, B, and AB) . I would have then created separate Solutions per Model Driven App and only the Model Driven App inside the Solution.

     

    In my experience however, there is never single right answer when it comes to ALM and I am glad your approach works for your scenario.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Users!

Kudos to our 2025 Community Spotlight Honorees

Congratulations to our 2025 community superstars!

Congratulations to the March Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Power Apps

#1
11manish Profile Picture

11manish 505

#2
WarrenBelz Profile Picture

WarrenBelz 502 Most Valuable Professional

#3
Haque Profile Picture

Haque 324

Last 30 days Overall leaderboard