When you create flows inside a solution you might have noticed these Environment Variables. What are they and what can you do with them?
Environment Variables in dynamic content
Recently these brown iconed Environment variables started to appear in Power Automate.
When we hover over the Environment Variable we can see that the function parameters is used for this.
When you read through the documentation of the parameters function things don’t get much clearer
How do Environment variables work?
First of all environment variables can be created within solutions only and also flows only find environment variables within solutions. So for example in my default solution there is a Should the Peek Button Be Showed [sic]
This environment variable appears in my flows as noticed earlier.
In your own solutions you can create new environment varibales.
These variabales can be plain text but also yes/no, decimals, json or even a datasource.
Well that creates a lot of options for us.
Data source type Environment Variables
A Decimal number. Text and Yes/No are hardly interesting. Yes of course you can set these variables and they are great to use, but how about a Datasource as an environment variable?
When I configure my SharePoint site like this as an environment variable:
Then that means that in my flow I can reference the variable instead of any hard coded urls. So that makes flow like this possible. Using the SharePoint list url without any selection of the drop down values.
Ok, that is great, but we need to put this to the real test. Using a trigger. in the past I managed to add settings to my flows using a number of compose actions or a select action near the top of my flow. But these variables that live outside my flow are so much better.
Even the editing experience is really good here!
Notice that I only set the Site address and i’m getting a drop-down with available lists! So the flow editor is environment variables aware.
You can now use this to set for example your SharePoint url or anything else that makes up the difference between your development, test and production environment. Such as who to send emails to.
Imagine creating a flow that emails senior managers in your organisation. You wouldn’t want them to receive your tests in development.
But,… I hear you say. Do I need environments?
I would always recommend using multiple environments. I’ve seen many times in the past where people pre or post fixed the names of their flows with DEV or TEST or PROD. Multiple environments makes things so much easier. And now that you can use environment variables on triggers and actions it should be a lot easier to move your flows as part of a solution.
How about Power Apps?
Well my next post is ready already.