Why?
Enterprise worthy Application Lifecycle Management (ALM) in the Power Platform 💪. I like the concept of Unmanaged Solutions for development purposes versus the concept of Managed Solutions for production purposes a lot!
However not all functionalities that “Dynamics Consultants” know from the Legacy / Classic experience (Dynamics Portal), are yet fully working for us “Power Platform Consultants” in the Modern Experience (App Maker Portal). Environment Variables is even a relatively new functionality that is exclusively available from the Modern Experience… 👀
What?
This is the first in a serie of blog posts. The serie is about my experiences with the Current Value of Environment Variables and using them in a (managed) Solution. Sometimes we need workarounds from the Dynamics Portal to fix an issue in the App Maker Portal and vice versa.
How?
I recommend to check on Microsoft Docs: Use environment variables in solutions – Power Apps | Microsoft Docs first if you are not yet known with the concept of Environment Variables. For this post it is focusing on the advantage to transfer configurable data from one Power Platform Environment to another. This gives us the option to include actual data while moving our solution through the ALM process. Simultaneously it provides the target environment with the option to change this data (later) if needed.
In my example, I have created a Power Platform Solution that combines Power Apps, Dataverse (Common Data Service) and SharePoint.
Because I want different SharePoint Site Collection(s) to be used in development (DEV) than in production (PROD), I decided to use Environment Variables.
With Environment Variables, I can make changes to my Solution in DEV linked to DEV SharePoint Site Collections. Then after approval of DEV, I can import the Managed Solution to PROD linked to PROD SharePoint Site Collections. Using the Environment Variables keeps all the Power Apps and Power Automate Flows linked to the right (Environment Variable) data.
1) First it is important to know that adding an Environment Variable to a Solution, relates to two Dataverse Tables (previously known as Common Data Service Entities).
- Environment Variable Definitions for storing the information about the data that you want to keep variable.
Here the Default Value of the Environment Variabe is stored as part of the definition record. - Environment Variable Values for storing the actual to be used data.
Here the Current Value of the Environment Variable is stored as the value record.
Theoretically you would not always need a Current Value, because the Default Value could be used. However there are big advantages in using the Current Value, so I decided to use it. In this case when exporting the Unmanaged Solution (DEV) to a Managed Solution (PROD), you have three scenario’s:
- You are a perfect developer and you never needed to use the Current Value to test. This is higly unlikely but this would leave you with an Unmanaged Solution in a Power Platform Environment that does only have a record for the Environment Variable Definition 🤓.
- You followed Microsofts advise and removed the Current Value from the Unmanaged Solution, before exporting it as a Managed Solution 🤐.
- You forgot or deliberately not followed scenario 2, before exporting it as a Managed Solution 🙄.
2) At the moment I, recommend to go for scenario 3 only. The reason of my recommendation is based on extensive troubleshooting with Microsoft Support. See: Solved: Re: Updating Environment Variables in Managed Solu… – Power Platform Community (microsoft.com).
I tried scenario 2 to update the Current Value from the imported Managed Solution but:
❌“This environment variable definition cannot be edited because it is in a managed solution.”❌
So there are some “product defects” or “bugs” at the moment. These made it nearly impossible to update the Current Value in the target environment 🤯.
Scenario 3 gives you the fastest way to update the Current Value of an Environment Variable. You need to open the Default Solution, look for your Environment Variable and edit the Current Value from here:
If you made the same mistake as I did and imported a Managed Solution without a Current Value, added a Current Value for the first time and cannot edit the new Current Value anymore… keep following this serie of blog posts. There is a way! 😉
I spent half a day trying to find where to customise the env vars (after all, that’s the point of having an env var).
MS “solution” to delete an env var before exporting is nonsense as if you want to make changes in your dev environment and test it you would need to set all env vars back.
Thanks for this much better approach!