Power Platform Solution Architecture: Working with Solutions

In this next post as part of my series on architecting solutions for the Power Platform, I’m going to focus specifically on working with solutions and some of the things we need to consider about them when working on implementations for the Power Platform…. READ MORE [https://lewisdoes.dev/blog/
anonymous female showing light bulb
Photo by Anete Lusina on Pexels.com
In: Low Code Lewis Content 🚀

In this next post as part of my series on architecting solutions for the Power Platform, I’m going to focus specifically on working with solutions and some of the things we need to consider about them when working on implementations for the Power Platform. Stay tuned to learn all things about ALM architecture for the Power Platform here friends! 🚀

What are solutions?

So to recap friends, solutions are the packages we can bring objects we build together into on the Power Platform to then use as movement boxes as such between environments through export and import actions. Recap more here…

Types of solutions

UnmanagedUsed during development for objects being worked on and to move objects to other development environments.
ManagedUsed to move working objects to non-development environments for testing, or productionisation.

Layering solutions

One of the really important points in solution architecture for ALM on the Power Platform and working with solutions is understanding how to layer solutions correctly and what this looks like.

Solution layers describe how solutions and versions of them are stacked on top of each other outlining the dependency chain of a component from the original or root solution that created or introduced it, through each solution that extends or changes it.

Unmanaged layerWhere active customisations sit that haven’t been imported using a managed solution. Not possible to uninstall by just removing the solution.
Managed layerCreated as part of imported managed solutions or ‘locked packages’ as such. When importing these one on top of the other, the last one installed (the top) solution is the one that will take precedence in customising the previous. Where two managed solutions have conflicting definitions the behaviour the user sees is the latest wins or the logic should be merged.

Considerations for solution architects

So, what do you need to be thinking about as a solution architect then? There are a number of things here… use these points as food for thought…

  • How we layer solutions and the strategy chosen to approach this
  • How we manage releases and layered solutions in the ALM strategy
  • How to structure solutions i.e. single, multiple or multiple with multiple shared components
  • Solution publishers used
  • Solution segmenting and not including all components for objects like tables.
  • Vertical or horizontal solution splitting

What’s coming up?

Written by
Lewis Baybutt
Microsoft Business Applications MVP • Power Platform Consultant • Blogger • Community Contributor • #CommunityRocks • #SharingIsCaring
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to LewisDoesDev.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.