Environment variables overview
Daniel Cieckiewicz
What must you know about environment variables?
In simple terms, environment variables in Power Platform help build solutions allowing users to use a specific parameter value within the entire solution and its components. If you use the same variable many times within your solution and you reimplement this one variable within different solution components, you can replace those with one environment variable. It even works if you migrate a solution to a different environment! An environment variable can have different values in other environments. You can also specify a default value that will be the same for all environments.
Business scenarios very often assume specific configuration parameters for solutions. It can be something like:
- database/server name
- data source
- environment name
- test/prod mailbox name
- API ID
- configuration keys and many more.
Environment variables are available to help you build Power Platform solutions faster. It also enables you to care about infrastructure and clarity of your component’s configuration. Instead of creating local variables in solution components or even hardcoding them, you can just set up one environment variable and use it everywhere. It is essential and very, very helpful.
Let’s hear what Microsoft says about environment variables.
Applications often require different configuration settings or input parameters when deployed to different environments. Environment variables store the parameter keys and values, which then serve as input to various other application objects. Separating the parameters from the consuming objects allows you to change the values within the same environment or when you migrate solutions to other environments. The alternative is leaving hard-coded parameter values within the components that use them. This is often problematic; especially when the values need to be changed during application lifecycle management (ALM) operations. Because environment variables are solution components, you can transport the references (keys) and change the values when solutions are migrated to other environments.
How to create environment variables
As mentioned previously, environment variables work with solutions. So, to create an environment variable, you must first create a solution. After that, go to “+ New,” choose “More,” and then finally click “Environment variable.” As shown below:
Now, provide a configuration for a variable. In my case, I will be creating two environment variables. The first is to know the current environment (whether PROD or not), and the second is to specify TEST and PROD mailbox names.
Check the screenshots below to see the configuration of those two environment variables.
The first variable tells me whether this is a PROD or DEV/TEST environment. I used the TRUE/FALSE variable type (boolean).
Warning!
If your environment variable should have a different value on different environments, don’t provide a Default Value! It is essential. If your Default Value is set up (even if the Current Value is blank), you will miss the “Edit environment variables step” during the solution import.
I don’t know if this is a bug or not. Microsoft tells us to remove a Current Value if we want to set up a new value for a different environment. But I could never see the “Edit environment variables step” during import when my variables had Default Value set up. This is just my experience, but I wanted to share it with you.
Why am I telling this? You will not be able to change your solution’s Default Value and Current Value if it is imported as a managed solution.
If you work only with unmanaged solutions, you will always be able to provide changes to your environment variables. However, the “Edit environment variables step” during import will still be missing for environment variables with a Default Value set up.
Let’s check this example. I have two Environment variables of the same boolean type. The first is called “isProduction,” and the second is called “test” – a unique name. 😛
Here is the configuration of those two environment variables:
isProduction:
test:
As you can see, only the “test” environment variable has the Default Value set up. And both of them don’t have Current Value. Let’s see what the “Edit environment variables step” during import looks like:
As you can see, I can set up a value only for an “isProduction” environment variable during the import. This is why I strongly encourage you to think before you will start implementing environment variables. Think about whether you will need to change this value later or not. If yes, don’t provide a Default Value. If not, give a Default Value. This is as simple as that.
One more thing – Remember always to remove the Current Value before export if you want to provide a different value for the environment variable during the import. You can read about it here: How do I remove a deal from an environment variable? Please also check this: Enter new values while importing solutions.
A pro tip
Suppose you made a mistake and missed the “Edit Environment variables step” during the import. Still, if you want to update your values for the environment variable, you can provide those changes via the Default solution.
Just find your environment variable on the Default solution on the target environment and change the Current Value! This is that simple.
I will tell you more about the export/import topic in the next chapter.
Back to the topic 🙂
The second environment variable tells me the name of the mailbox that should be used within the solution. If it is DEV/TEST, I will use the “contact_test@poweruniverse.org” mailbox. For PROD, I will be using “contact@poweruniverse.org mailbox”.
In this example you can clearly see that I provided a Default Value even if I want my PROD environment to have a different value. This is because I am going to remove the Current Value before the export, so Default Value will be used and it is alright. And I will not be setting a new value during the import.
I implemented those variables on the DEV environment, so this is why my “Current Value” for the first variable is set to “False.” It will be changed after I migrate the solution to PROD.
This is basically how you create and configure environment variables for a solution.
Export and import tips
I will really quickly go through this topic, because I covered it mostly before.
There are couple of rules for migrations.
Don't provide a Default Value and remove Current Value
Don’t provide a Default Value for environment variable if you want to set this variable during the import. Remember also to remove Current Value before export if you want the same. It just works like that. You will not be able to set up environment variables that have Default Value or Current Value set up.
Be aware of True/False environment variable type
If you will set up a Default Value for a TRUE/FALSE environment variable, you will not be able to change it later. So, you will also miss the step of setting up this environment variables during the import.
You can change for example the Datasource or TEXT type Default Value, but not TRUE/FALSE
Provide a Default Value if
Provide a Default Value for your Environment Variable if you don’t want to provide changes to it after the import. If your environment variable’s value will be the same for every environment, provide Default Value and forget about the configurations of this variable.
If you import as a managed solution
If you imported a solution as managed solution and you want to provide changes to your environment variables, you can always go to the Default solution and make your essential changes. You won’t be able to modify components from a managed solution.
How to use environment variables
I will show you how to use environment variables on Power Apps and Power Automate examples.
Power Apps
In Power Apps Canvas Apps, you must first add “Environment Variable Definitions” and “Environment Variable Values” Dataverse tables to your application. They contain values and definitions of our environment variables.
To access your environment variable value, provide this line of code:
LookUp(
'Environment Variable Values',
'Environment Variable Definition'.'Display Name' = "isProduction"
).Value
As you can see, I have just accessed the value of this environment variable called “isProduction.” Now I don’t need to initialize it here again. I can start working on it.
Power Automate
For Power Automate, working with environment variables is even simpler! You provide a name in action, and that’s all. If you are working with a cloud flow included in a solution, your environment variables should be available immediately. Check the screenshot below:
You can start working with environment variables in your Power Automate flows. I have a pretty good example for you.
Example
You can use the “isProduction” environment variable if, for example, you want to send an email using a different mailbox. The subject/content or real action can be other for different environments. Let’s check how email action is configured.
This is the first approach:
The original mailbox name will differ for PROD and DEV/TEST environments. So, I can do something like this.
I can also configure the entire email action if I want to. Like this:
There are many other ways to achieve this. This is just an example.
You can also specify whether you want to send an email to a real user. There are many scenarios when you do not wish to email real business users. Then you can set up another environment variable just for receiving emails for testing purposes. Not to create an infinite loop.
I created another environment variable with only a default value, the same for all environments, and will allow developers to send emails to this mailbox.
Then, I used my environment variable like this:
if(
equals(
parameters('isProduction (rc_isproduction)'), true
),
variables('RealUserMailbox'),
parameters('MailboxForTesting (rc_mailboxfortesting)')
)
I hope you find those example useful!
Final tips
- When environment variable values are changed directly within an environment instead of through an ALM operation like solution import, flows will continue using the previous value until the flow is either saved or turned off and turned on again.
- When editing a cloud flow, if an environment variable is added in another browser tab, the flow needs to be reopened in the flow designer to refresh the dynamic content selector.
- SharePoint Online is currently the only data source supported for environment variables of type “data source” within canvas apps. However, the Dataverse connector will be updated soon for when connectivity is required to Dataverse environments other than the current environment. Other types of environment variables may be used within canvas apps by retrieving them as you would record data via a Dataverse connection.
Summary
In summary, you should use environment variables with your solutions as much as possible! They are very, very useful. They help you build solutions in a more structured way without a need to reimplement repeating variables for every different solution component. You can use environment variables in many places.
But, as shown in this article, there may be some potential problems with your environment variables. Always think twice before implementing them and be sure to configure them correctly.
I hope you find them helpful!
So, finally, we are at this point where I should thank you for your time and for reading this article. Feel free to rate this article and comment if you liked it. If you have any questions, feel free to contact me (via contact@poweruniverse.org), but first, you may be interested in joining a Newsletter. Hmm? (Sign up here) If you already did, wow, thanks, thanks a lot 
Via Newsletter, I am sharing insights into my work, plans for upcoming weeks, and knowledge about Power Platform Universe and the IT world. If you are interested, feel free to join! I am going to send the latest Newsletter to everyone who enters!
See you!
Daniel Ciećkiewicz
I am a Senior Power Platform Consultant focused on Dataverse, Power Apps, and Power Automate. I was also a Team Leader responsible for the Power Platform Team and their development paths.
In my private life, I like video games, sports, learning & gaining knowledge, and a taste of good Scotch Whisky!
Ooo, I almost forgot, I love our Polish Tatra Mountains!
Power Apps Licensing Explained
Power Apps Licensing – this is something every Power Platform expert must know. In this article I will walk you through the cons and pros of available plans.
Understand Delegation in Power Apps
In this article I will walk you through delegation in Power Apps and I will show you many interesting concepts how to work with delegation and understand Delegation in Power Apps!
Connection vs connection reference in Power Platform
In this article I will tell you what is the difference between connection and connection reference in Power Platform. It is very good to know the advantages.
Overview of a Tenant Isolation in the Power Platform
What is Tenant Isolation in the Power Platform? How does it work and how do you know it will be good for your organization? Check the article!
The most interesting Power Platform features of 2024 – Wave 1 update
Do you want to know what updates are coming in 2024? This article will tell you more about incoming updates for Power Platform in Wave 1.
Use a Service Principal to run Dataverse actions in Power Automate
Do you want to learn how to use a Service Principal to work with Dataverse actions in Power Automate? This article is for you. Check it out.
[…] Apps Licensing Explained, Environment variables overview, or Create and use Dataflows in Power Apps, you can develop your technical skills. […]