(Some obvious/ well known stuff… but in case it helps anyone or me later on)
When you have Power Apps or Flow (aka Power Automate) it is good to put them into Solutions as that captures the App/ Flow, its connections, and can also include any child Flows etc. In fact, I think it’s better to always just use Solutions coz I ran into this error wherein when I added an existing Flow into a Solution it kept complaining that the parent Flow and the newly added child Flow are in different susbscriptions (turns out Flow makes use of Logic Apps and Azure behind the scenes) and so I couldn’t connect the two together. Numerous forum posts suggested recreating either the parent or child which seemed like a pain in the backside. I ended up recreating the child Flow but I learnt my lesson the hard way that day – always start with Solutions.
Once you do Solutions you can also do an export/ import of them. This is useful if you have multiple environments. For instance I am developing my Flow as and when I strike upon an idea; but obviously I don’t want to touch the version of Flow that is in production and used by the users. Thus I can have a production and a development environment, and have the same Flow in both environments. In my development environment the Flow is “unmanaged” (doesn’t mean anything on its own, but read on…) while when I export it I can do so as a “managed” solution and import into my production environment. By exporting a flow as “managed” when it is imported into the other environment it is read-only; thus I can’t mistakenly make any changes to my Flow in the production environment. The only way to make changes there is to make changes in the development environment, export and import into production – which is good, it forces good practices.
To be honest I am still learning about Solutions, but a good starting point to read about it is this blog post and if you want to delve deeper this doc.
One useful thing to use along with Solutions is Environmental Variables. Say your Flow refers to a Microsoft Form or an Automation Account. You might want the dev and prod versions of your Flows to use different variants of these. How can you achieve that? You do so via Environmental Variables. These are variables that exist outside of your Flow and you create them in the Solution where your Flow is contained and set a value for them specific to that Environment.
Once you create an Environment Variable within a Solution 1) ensure you set no Default value for it and 2) remove its Current Value from within the Solution. Then if you export the Environment Variable and import into another environment you can a separate value there. When you remove the Current Value from a Solution the value continues to exist in the Default Solution of the environment and that’s what gets picked up by the Flow while it runs. Similarly when you export & import into the other environment you set a value in the Default Solution of that environment.