Having a Dynamics background, I am used to deploying solutions through dev/test and production using managed solutions.
When Power Automate came along instead of traditional Dynamics workflows, I kept on the managed route. Which is fine if the Flows only contain DataVerse actions, but if they contain Outlook connectors or SharePoint, it starts to get more fun. Connection references are now a thing, but they still do not deploy very well using DevOps pipelines, unless you start using PowerShell.
Now I work mostly in the (DataVerse) PowerApps world, I’ve come to split my app solutions into 3 separate solutions:
- Managed solution : All DataVerse only Flows and tables. These will always run under a service principal account, which will already exist in each environment for easy deployment. Canvas apps can be included here too if only using DataVerse as a data source.
- Unmanaged solution: All Flows that use non DataVerse connectors. Sometimes, one needs to go and edit the Flow when deployed to a new environment – think a SharePoint connection to an Excel file.
- Unmanaged solution: All environment variables required in the first 2 solutions. I see no value in deploying these more than once into a new environment. Once they are there and the values set, they will never change, and it’s so easy to deploy them forgetting to remove the local values.
There are also good reasons to separate out Option sets (Choice(s)) into their own solution, as these often need to be updated for business reasons with an extra value, and it just simplifies the release process.
I’m sure my ideas will change over time, and especially as Microsoft add more functionality to solution deployment and to DevOps pipelines.