You have to at least have an environment set up for your target location, which I also believe implies there is a dataverse database behind it. We did much of our development before some of the recent ALM features came out in power automate, so we still have some flows in the ‘default’ environment and are still trying to get them all sorted properly. If you’re just starting the process, then it sounds like you first need to create a solution in your default dataverse and move your flows into it. You can use the solutions to group your flows based on functionality / security / however you want to manage them. Once that is in place you can convert your connections to connection references. That’s much handier for testing on a dev database and later moving to production. My advice here is to use as few connections as possible,; the GUI wizards make it entirely too easy to create new connection / connection reference objects instead of re-using existing ones. It’s too easy to create the same connection with the same name, but different guid id which makes things harder later. Also use care in object naming – you want to use your own publisher for the solution so your objects can be named <myid>_<objectname> rather than public_<objectname>. As part of a dev-test-prod lifecycle, you can export the solution from one environment to the next. There are a few references on Microsoft Learn for best practices, here’s a starting point: https://learn.microsoft.com/en-us/power-platform/alm/overview-alm.
Please note:
This action will also remove this member from your connections and send a report to the site admin.
Please allow a few minutes for this process to complete.
Report
You have already reported this .
Welcome to our new site!
Here you will find a wealth of information created for people that are on a mission to redefine business models with cloud techinologies, AI, automation, low code / no code applications, data, security & more to compete in the Acceleration Economy!