Power Platform | Makers & Environment Variables

I recently provided two reviews of Power Platform Pipelines after becoming general available. A first one which was about the Makers experience and a second that covered the Admin experience. Today, I´d like to talk about another Maker’s experience – this time when working with Environment Variables. Truly something which doesn´t come top of mind, but in reality can be found quite often due to being related to a couple of use-cases, such as:

• Flows or Apps where there´s a need for a reference to a SharePoint site or List
• Flows or Apps that are in need of an Azure Key Vault stored secret
• A JSON that is used for app theming
• A URL that is referenced from an App or Flow that will change between Test, Dev, Production.
• …

Makers may start creating their solution from Power Apps Studio such as I did in my example shared below.

Overview of solution artifacts

This might end up in something like above where me being a Maker created a SharePoint List Name and afterwards created a Power Automate flow that is using the Environment Variable created to ensure that it points to the right location when moved from Development to Test and later on from Development to Production after a succesful test.

Of course I followed the principles that can be found here. Everything was working fine, so I started the Pipelines process of moving my solution to Test.

Pipelines Deploying Solution Dialog – showing Connections

The dialog I was presented with looked like above visual. From a solution perspective it makes sense as my solution also contained a connection reference that was used in my flow, so I first didn´t stepped about any issues with that. Though when hitting next after validation, I wasn´t presented with another dialog window that asked me about the change of the Environment Variable. So what happened here?

I needed to do some research, before inside earlier shared learning material, I came across an important note:

You will not be prompted for new values during solution import if the environment variables already have either a default value or value present; whether values are part of your solution or are already present in the target environment.

Use environment variables

Since I created my solution artifacts above and to ensure storing my flow that inside the trigger contained the environment variable, I needed to provide a value. Otherwise it wouldn´t let me saving my flow as it contains a non-valid value for the List Name.

Flow logic that shows the usage of an Environment Variable both inside Trigger and Action

You know what happened next? I started to create a new solution that contains an Environment Variable only. This time, I didn´t provided any Default Value.

Overview – Solution Artifacts – Environment Variable only

After creating and publishing all customizations, I continued by testing Pipelines again.

Pipelines – Deploying Solution Dialog – Asking for Environment Variable value

This time, I was asked to provide the value for my Environment Variable. And because of that I could now move an Environment Variable between Environments. Still though, from a Makers perspective that is new to solutions concept and now even new to Environment Variables, it doesn´t feel intuitive and a restriction that causes some pains.

For example, as I outlined a Maker would typically start creating their artifacts in a solution (because of being trained that way). Furthermore, they would provide a standard (default) value for the development environment, especially if they want to use it inside a flow trigger. Otherwise the flow cannot be saved and an error occurs that you need to provide a value. But as we learned today, this causes not to be asked for a different value when moving your solution to Test or Production via Pipelines (by the way this is also true for Azure DevOps, ALM Accelerator or GitHub Actions, so not specific to Pipelines).

Creating artifacts which contains an empty definition or value for an Environment Variable feels counterintuitive and is only possible in a limited way from a creation perspective.

Does it mean to create a solution that stores and shifts Environment Variables first and then later on use exactly those pre-configured and pre-moved inside your solutions? For the moment it seems the only correct answer to this.

This obviously adds a complexity to the Maker process itself and hopefully we´re going to see changes to this concept in short time. Otherwise, Makers may be running into a trap here where them using default values for their Environment Variables while creating artifacts and later-on having trouble of moving those Environment Variables between environments and ensuring to always point to the correct values. This would cause a more professional or ALM-process-knowing Maker to take a look into what happened here and of course is a frustrational experience for Makers.

Let me know about your experiences with Environment Variables from a Maker´s perspective and as always, ensure to use the official feedback channels via submitting ideas so that the engineering team becomes aware of an improvement needed. Until then,…

• ALM
• Pipelines