I'm looking for advice on how to manage (solution-aware) Flows that move between environments. Right now the whole process seems woefully hard so I'm certain I'm doing something wrong!
Simple example - I have a Flow that is triggered in CDS (I can now use the CDS "Current Environment" connector - that's one thing off the list!). When a record is created, connect to SharePoint and then create a file or folder there. In this scenario, I need to switch connections to SharePoint between each environment (i.e. upload to the Sharepoint online subsite for DEV or TEST or PROD) but also some Sharepoint actions require me to also specify the name of the subsite as a string (e.g. "subsite-dev", "subsite-test", "subsite-prod" etc).
How do I best manage thiese dependencies? I imagine that I could create a Settings entity in CDS that allows me to set some constants. This could work where I need strings but 1) I don't see this working for Connections and 2) seems inefficient to have to read that setting on every transaction.
Can anyone point me to a best practice blog, article or post that gives some guidance; I know this isn't a unique issue but I can't seem to find the right search terms to get to the answer I need!
Hi @GreySnowOgre ,
I understand roughly what you mean is that there are three environments, and there is one SharePoint in each environment. You want to create a flow so that SharePoint data in these three environments can be exchanged, right?
Although environments provide many benefits, they also introduce new limitations. The fact that environments are an isolation boundary means that you can never have resources that reference resources across environments. For example, you may not create a SharePoint connection in one environment and then create a flow that uses that SharePoint connection in a different environment:
Community Support Team _ Lin Tu
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
Thanks for your reply Lin, but I think my question is wider than simply understanding the challenges of environments. There are many situations where variables/constants that are appropriate for development or test scenarios are not appropriate for production. This could a path, a username, a record id, a url... What I'm seeking here is some advice to best manage such variables at design time in Flow so that I can minimise the risk of propogating a Flow from a TEST scenario to a PRODUCTION scenario and make sure that everything points in the right place. Connections are part of the same problem, though there may be a different solution there.
I'm simply looking to understand what is the recommended approach at design-time to help manage these problems.
In the case of my Sharepoint example earlier, I am not using "Environments" (note the captial letter) rather have a choice of Sharepoint subsites thatI should write to; the one I use for production has the same structure as the ones I use for development and test, they just differ in the URL at the top level. How would I most efficiently ensure that my TEST Flow points to the TEST Sharepoint subsite and my PRODUCTION Flow points to my Production subsite?
it seem that there is a new option as u can now automatically create Power Platform environment variables when connecting to SharePoint list in a Canvas App (and also in Flows), and when importing Canvas app in other Environment it will ask for which SharePoint list to use... see a demo of it here Now it is time to be Curious about Power Platform Environment Variables! (iiu.dk).... this might be what u where looking fore 🙂
The first Microsoft-sponsored Power Platform Conference is coming in September. 100+ speakers, 150+ sessions, and what's new and next for Power Platform.
Announcing a new way to share your feedback with the Power Automate Team.
Learn to digitize and optimize business processes and connect all your applications to share data in real time.
Join Priya Kodukula and the licensing team, super users and MVPs to find answers to your questions on Power Automate licensing.