Working with Environment Variables in Canvas Power Apps and Power Automate Flows

No two software deployment is ever the same. As IT professionals, we will often need to tailor our solutions, to ensure they operate within separate environments, such as development, test, production and anything else in between. From a Power Platform / Dynamics 365 standpoint, there has been some long-standing capability here to help address some of these needs, via features such as secure/unsecure plugin configuration. However, the main limiting factor behind these has been their limited applicability; more correctly, we can only use them if we are leveraging plug-ins as part of our solution. If, for example, we wanted to tailor our deployments and utilise different values for our canvas Power Apps, Power Automate flows or any other solution, we would have to rely on a workaround, using a new custom entity or similar. Having to factor in the development time and effort to support this can be debilitating to the progress of a project.

It was pleasing, therefore, to see Microsoft introduce Environment variables into public preview late last year. This announcement addressed a long-standing community ask, as well as helping to expand out the Application Lifecycle Management (ALM) capabilities of the platform. And, thanks to the fact that the feature is generally available, we can now happily utilise them as part of our live, production deployments. But how do you go about setting them up? And how do you then utilise them using canvas Power Apps and Power Automate flows? Well, it’s funny that you should ask. 😀 As this so happens to be the focus of today’s blog post. Scroll on to find out more!

Creating Environment Variables

Rather than repeat what’s available out there already, I’d advise taking a look at this great Microsoft Docs article, which provides full instructions on how to create them. Suffice to say environment variables can:

Be included as part of our solutions.
Support a variety of different data types, including JSON objects.
Be assigned a default value, which the platform will use if we specify no current value.

Setting the Current Value

Each Environment Variable must have a current value, which we can set in one of two ways:

Via the Maker Portal: If you navigate to the Environment variable within your solution, you will have the option at the bottom of the pane to supply this value. I would recommend that if you are exporting out to another environment, that you remove this from the solution first; this will retain the value in your current system but prevent it from being automatically filled in when you import into your target environment.
On Solution Import: Using the new solution import experience (which I touched upon in last week’s blog post), we get the option to set the current values when importing the solution for the very first time. In the example below, three Environment variables require specifying as part of the solution import:

From there, you can look to leverage them from within your canvas apps and flows. Let’s take a look first at how to use them for your apps.

Using in Canvas Power Apps

First, make sure that you have added the following two entities into your canvas app:

Now, you can then use the following code snippet below to grab the current value of your chosen Environment variable. In this example, we are retrieving the current value of an environment variable with the schema name jjg_myvariable:

Set(myVariable, LookUp(
    'Environment Variable Values',
    'Environment Variable Definition'.'Schema Name' = "jjg_myvariable",
    Value)
);

A suggested way of calling this, if your value needs to remain static across your app, is as part of the OnStart event handler. But with the above snippet, it is conceivable to call this anywhere in your app.

Using in Power Automate Flows

Update 22/11/2020: There is a better approach towards achieving the below, which improves performance and makes your flows more readable. Please check out this follow-on post, which outlines the alternative approach in detail.

This time, there’s a bit more setup involved. First, we create a string variable which will store our environment variable value:

Next, we then need to retrieve the details of the Environment Definition record, using a list records step similar to the below:

List records will always return multiple results but, in this circumstance, there should only ever be one Environment variable definition record that comes back. Also, we have no easy way of knowing what the unique ID of this is, so running a query based on its schema name is the most streamlined solution on offer. Taken this into account, therefore, we must then wrap around our next step - getting the current Environment variable value - within an Apply to each action step:

In this case, within our filter query, we are supplying the ID of the Environment variable definition record from our previous step.

Next, and finally, we use another Apply to each to iterate through our result set and assign the Environment variable value to the variable declared earlier. Once again, you should only ever have one record return here, so there’s little risk of us setting an incorrect value here:

From there, you can then build out your flow and utilise your environment variable value in any way you see fit.

Environment variables provide a useful and, perhaps, long-absent capability to help us tailor our Power Apps / Dynamics 365 online deployments. They are also sufficiently “modern”, in the sense that we can use them straightforwardly across a variety of tools within the Power Platform. I hope this post has been useful in explaining what they can do and, more importantly, how you can start using them as part of your next project.