Save Time Building Your Flows With Environment Variables
If you're a no-code/low-code developer and you're not using environment variables, you could be missing out on the ability to better keep track of, adjust, and collaborate on your data.
What is an environment variable?
To put it simply, an environment variable is a placeholder that can contain important data values for your applications or flows. Environment variables can store a variety of types of data including Text, Numbers, Data sources, and even JSON blobs.
When considering environment variables, think of them as being like Global Variables or Constant values that can be used throughout your application, which are often used in traditional application development.
Here‘s some common scenarios where environment variables are useful in the Power Platform:
- You have multiple flows that run an end-to-end business process and they all use the same SharePoint list.
- You have a Canvas application that provides additional functionality based on who is specified as the “ADMIN” user, and you want to make this configurable without making changes to the app itself.
- You need to support application lifecycle management and your applications and flows should be pointed at the correct data source depending on which part of the lifecycle they are in (DEV / TEST / PROD).
Why should I use environment variables?
So, I alluded to some things in the examples given above, but why is this so important?
- One source of truth: If you have common data values, data sources, and connections used throughout your applications or supporting processes. These may be used to identify where to get data from, where to store data to, or even how the app or process should “behave”.
- Easy to reference: When you’re building your apps and flows, environment variables make it easier to reference the key data values that you need. Once created, you can reference these in other components of your solution.
- Easy Adjustments: Once you are using this across your solution, if you ever need to change one of these values, you’re only doing it in one place, instead of opening each app or flow to make the change.
- Improves collaboration: If you’re working with a team of developers, this makes it easy for everyone to be on the same page. Ever had to message your team and tell them all to update their connections because you had to recreate something?
- Facilitates Application Lifecycle: Create environment variables in your solution and you can easily move from development, to test, to production. Each environment can have independently managed data.
How To Use Environment Variables
For any of this to work you should be creating things inside of a Solution. So, if you have a collection of flows used for a specific business process, or maybe you have a Canvas App and some flows all working together, these need to be in a solution to take advantage of environment variables.
Want to learn more about environments and solutions? Check out our guide here.
To do this, navigate to your target Power Platform environment and select the Solutions tab in that environment. You can select an existing solution if you have one in mind, or create a new solution.
You can then add any existing apps or flows from your environment to your solution. Otherwise, you can start creating things inside of your new solution, including environment variables.
Side note: I want to call out that in Canvas Apps, whenever you connect to data (SharePoint for example) environment variables of type Data source are kind of magically created “behind the scenes” and outside of any solution. You must add these to your solution by adding an existing environment variable if you want to use them to manage connections from one environment to another.
Now let’s create a variable. I’ll create a simple Text value, `baseUrl` that points to my App Data site.
Using it in a Flow
Once created, you can easily reference these values from your flows. They'll show up inside your dynamic object dialog as shown below.
If you’re building a flow that is not in a solution, you will NOT see environment variables here.
Using it in Canvas Apps
When it comes to Canvas Apps, it’s a little trickier. Microsoft doesn’t offer a built in way to directly access Environment Variables from a Canvas App. This means you have to connect to the Dataverse table. Since this creates a licensing issue, there are two approaches we will go over.
If you’re dealing with paid Power Apps licenses already, you can directly access the environment variables within your Canvas App using a Dataverse connection.
Caveat: Technically, if you’re using this method, you can retrieve environment variable values, in a Canvas App, outside of a solution. Maybe there’s a gap here @Microsoft?
And by the way... this method can be free using Dataverse for Teams. You just have to wiggle your way into the Power Apps management in your Team. There you can add an environment variable. Then in your Apps that live in that same environment, you can reference those variables the same as shown next in this post.
Ok, sorry let’s get back to the task at hand.
Using a Data Connection
This approach will work if your users have a paid Power Apps license already or you are working within a Dataverse for Teams environment.
Open the Data Panel and add a connection to the ‘Environment Variable Values’ Dataverse entity.
Then you can use the `Filter` or `LookUp` function (depending on your scenario) to get your value.
`LookUp('Environment Variable Values', 'Environment Variable Definition'.'Display Name' = "baseUrl").Value`
Using a Flow
The second method for getting these values into your Canvas App, which is also free, is to use a flow to retrieve the value. In my example we created a flow that is called from the Canvas App. You might run this somewhere in the startup of your app, or a button click depending on your scenario.
Note for if you want to go even deeper: ALL environment variables defined for an environment are available to ALL solutions in the environment. So technically, you can have environment variables defined for the environment (maybe in a dedicated “configuration” solution) and all other solutions in that same environment can use them. This becomes handy when we find ourselves with dedicated shared environments where multiple solutions or apps, developed independently, are using the same organization resources or locations.
Taking it to the next level - How to use Default vs. Current values
Alright, so if you've made it this far, then you care enough to go the rest of the way. This little walkthrough will save you time in figuring out how to use and manage environment variables when moving from one environment to the next.
The first thing to call out is that you can specify a default value for an environment variable. A default value is used whenever the environment variable does not have a “current value” specified. In terms of the app dev lifecycle, this concept can be used to effectively set a value that needs to have a “fallback” value.
Additionally, setting a default value can be an effective way to set a variable that will remain the same across environments. Simply put, when you export an environment variable, the default value will come with it.
The next thing to talk about is what it means to set “current values”. If you set a current value for an environment variable, anything in your environment will use that value instead of the default value (if one is defined).
Now, if you’re manipulating the current value from within a solution, the thing to be careful of is exporting the current value. The assumption is that when you export with a plan to deploy to another environment, you’re doing this as a managed solution, which means you cannot make changes in the target environment. This includes changes to environment variables. If you make this mistake, you may be left scratching your head, wondering how to set the environment variable values after you deploy.
The right way to manage Environment Variable values:
- Set the current value in your development environment.
- Select the environment variable, current value, and choose `Remove from solution`.
This is the key. It will remove the current value from the solution but not from the environment. This leaves your development environment functional, but keeps it unspecified in the exported solution package.
- When you import the managed solution into your target environment, you’ll be prompted to provide values for any environment variables that do not have a current value specified.
That’s how it is supposed to work.
But what if you find yourself stuck with environment variables in a managed solution and the current values are already set and you need to change them? If you’re going through the solution manager, you’ll be stopped from making these changes.
Fortunately, there are some workarounds. You’ll likely need to be an admin in the target environment. If you are, one way you can access the Environment Variable Values table directly is from the list of Dataverse tables.
Open this up and edit the data directly by using the Edit data in Excel option. Not sure if this will be around forever, but it’s available at the time of this post.
Workaround? Yes. Standard method? Nope. Security hole? Probably.