Dive into Working With Environment Variables

When you have graduated from just building simple apps and workflows in Power Platform, you will likely encounter a need to use application lifecycle management (ALM) to manage your solutions and environments. Environment variables are a powerful tool for keeping your apps and flows up to date, but that’s only if you understand how to use them.

What Are Environment Variables?

Building cloud flows and getting them to work is an amazing accomplishment, especially if you’ve never built a workflow before. When you are ready to mature your Power Platform practice, you will likely start exploring the world of solutions, environments, and ALM. This article is not going to cover all those things but will instead deep dive into one aspect of solutions: environment variables.

For a quick overview, solutions are types of containers into which you can put your apps, flows, and their components. Solutions are useful for organizing all your resources. This is because there can be many components related to apps and flows that can also be organized into solutions. Solutions are especially useful for ALM, which involves moving solutions between environments, typically Development, Test, and Production. You can read more about ALM in Power Platform at Microsoft Learn.

One component that you can bundle into a solution is an environment variable. An environment variable in short, enables you to avoid hard-coding values into your apps and flows. You can use an environment variable just like you would use dynamic content in a cloud flow, for example. What controls the value that is inserted when the flow is run, however, isn’t based on the context of the flow at all.

What Are the Basics of an Environment Variable?

When you make a new environment variable, you first must be inside of a solution. Next, you select New, and then navigate the menus until you find Environment variable. This is what will pop up.

There are various data types that you can select, but the most common one (and the one these tests were run with) is text.

Once you’ve closed the pop-up for identifying the data type, you will see an option to put in a default value and a current value. We will go more into these two types of values in depth later, but in short, the current value is going to override whatever is in the default value field. Also notice that neither of these fields is required when you first make your environment variable, so it is okay to leave it blank at first. I tend to just utilize the default value, but here’s what Microsoft has to say about the current value:

“Separation of default value and current value allows you to service the definition and the default value separately from the value. For example, an application publisher may list their offer on AppSource with a default value. Then optionally, the customer can provide a new value. When the application publisher publishes updates to the application, the value set by the customer won't be overwritten.”

What Is an Example Use Case?

An example may be helpful here. I recently created a flow to email out a Power BI report monthly. I wanted this flow to follow ALM, so I created it in my Development environment. Because users change their minds, I knew that I didn’t want to hard-code the text of the email that would be sent out monthly with the report. This means that I couldn’t edit its text in the future. So, I created an environment variable that stored the original text of the email, and I inserted that environment variable into the body of the email. I exported that solution and then imported it into my Test environment as a managed solution, meaning it could no longer be changed. I could still edit the email text, however, not by modifying the flow but by modifying the environment variable itself. When the flow was then run in the Test environment, it looked at the most recent value of the environment variable, and the updated email text was sent out. Aside from the text box being too small (I just edited it in another window), it worked well.

To summarize, I use environment variables because once an app or flow has been migrated to a managed solution, which is what is recommended for Test and Production environments, you can’t edit them without making an unmanaged layer. Environment variables are useful when you might want to change the location of a SharePoint list or change who an approval is assigned to, among countless other use cases.

What’s the Problem with Environment Variables, Then?

You may be thinking that this sounds awesome and are ready to implement this in your next solution, but you might want to keep reading before diving in fully.

Take the example from Figure 2. You can see that Default Value is an editable text field at this point. Notice that this screenshot was taken from a Development environment in an unmanaged solution. What does this same environment variable look like in a managed solution in a Test environment?

As shown in Figure 3, notice that now none of the fields are editable, which seems to go against what you just learned about how to use environment variables!

The Current Value field isn’t even an option on this screen. But wait, I thought the whole point of an environment variable was that you could still edit it in a managed solution. Well, you can, but that is where I had to do some digging and experimenting.

How Does the Default Value Work versus the Current Value?

For the first of the experiments, I created a solution with a single cloud flow in it that, when triggered, would post a message to Teams with the values of my environment variables. I made two environment variables—NoDefault and YesDefault. As may be apparent, I created NoDefault with a current value in it—Lindsay rules.

For later, see that little note at the bottom? Remove this value before exporting if it shouldn’t be used in other environments. You won’t get that note on a default value. This leads me to believe that the current value is intended more for temporary or personal uses than the default value is.

For my second environment variable, YesDefault, I gave it just a default value of Lindsay rocks. (You may start noticing a theme, but I figure it’s good for self-esteem.)

I then ran my flow, again in my unmanaged Development environment, and got this result (which I expected).

Next, I decided to remove the current value of Lindsay rules in my NoDefault environment variable, and then I exported my solution as a managed solution before importing it to my Test environment. Again, the NoDefault environment variable had neither a default value nor a current value when I exported and imported it. Upon import, I got a welcome new prompt that I hadn’t seen before.

I entered Lindsay is awesome, saved it, and then ran the flow again. This was the result.

So, my new value of Lindsay is awesome did come through. When I checked my environment variable, the default value was still blank, meaning Lindsay is awesome got added as a current value. However, I couldn’t see the current value, so where was it being stored?

Further Adventures and Caveats with Default and Current Values

I played around further and found that if you make a variable with no default value but do have a current value, it displays the current value when used and migrates between environments with no problem. That led to a further deep dive that helped me discover something else.

So, I removed the current value from my new variable, NoDefaultYesCurrent, and tried to run my flow again. However, I was still getting the old current value. I tried publishing customizations and checked repeatedly, but I couldn’t get rid of that old value. This led me to Microsoft documentation:

"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."

I tried turning my flow on and off and instead got an error almost instantly that said the following:

Flow client error returned with status code "BadRequest" and details "{"error":{"code":"XrmEnvironmentVariableAttributeNotFound","message":"Attribute 'value' was not found for environment variable….

The flow wouldn’t turn back on again until I went back and put in a different current value.

Another lesson learned: don't remove the current value and then turn your flow on and off; you will get an error.

But How Do You Edit the Environment Variable in a Managed Solution?

That takes us to the ultimate problem—it didn’t appear that it was possible to edit the environment variable once I’d gone to a Test environment with a managed solution. That’s key to ALM, so I was getting frustrated at this point, until my friend Nathalie Leenders pointed me to the Default Solution. Yes, that is confusing when we are already dealing with default values and managed solutions, but it is what it is.

In every environment you have, when you look at your list of solutions, you have by default an unmanaged solution called Default Solution.

Select Default Solution, and you will see an overwhelming list of components. Use the navigation on the left to filter just environment variables, and then you will see all that environment’s variables at once. Select one of those variables, and you will suddenly see that what was greyed out before is now editable (except for the internal name, which must stay the same).

Changes that you make here will appear in your apps and flows with one caveat. Changes may not take effect until you turn the flow off and on again. Again, as we found earlier, the flow won’t turn on again at all if you remove your current value and then try it.

Key Takeaways

Based on my experience and experiments, here are some key takeaways about environment variables:

• Whatever is in the current value overrides whatever is in the default value.
• You can create an environment variable with no values at all, a default value and a current value, or some combination of the two.
• You can edit the default and current values in a managed solution by editing the Default Solution, but those changes potentially won’t take effect until you turn the flow off and on again.
• To make it so the solution prompts for a new environment variable value:
  • Leave the default value blank.
  • Add something for the current value.
  • Go back to the current value and click the three dots next to it.
  • Select Remove from this solution.
  • Now the current value and default value should be blank.
• To edit an environment variable in a managed solution, go to the Default Solution and edit it there.

Conclusion

Environment variables are incredibly useful in apps and flows, enabling you to edit content without violating ALM procedures. They do have some quirks to them, like learning the difference between default and current values and figuring out how to edit them when in a managed solution. However, now that you are armed with the results of many experiments and deep dives, hopefully you will avoid having to figure out all the ins and outs on your own and can carry on making amazing solutions.