A number of folks have pointed out that solution environment variables are, now, in preview:
https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/environmentvariables
I was looking at it yesterday, and, it seems, I’m having a bit mixed emotions.
Environment variables seem to represent a hybrid experience: we can work with them in the model-driven application, but we can also work with them in the solution designer.
For instance, I can find Environment Variables Definitions in the advanced find, run a query, get the list, and review the variables:
I can even update the values on the screen above:
Then, if I open https://make.preview.powerapps.com/ (notice “preview” in the url), I can, then, open the same environment variable definition in the admin experience. As you can see on the screenshot below, the change I’ve made in the regular interface is, now, reflected in the admin interface as well:
In other words, it’s a regular (well, not quite regular, but still) entity that’s also exposed through the admin interface. Come to think of it, that’s not that unusual since there are, also, entities for such “metadata” as views, for example. So, maybe, at some point environment variables will simply be hidden from the regular user interface.
That’s, really, just a little unusual twist, but what’s really interesting is the usage scenarios.
First of all, we can include environment variables definitions into our solutions. And, then, we can also include special json files which will overwrite those default values.
Basically, when using the solution packager to re-package our solution, we can choose to overwrite those values in the destination depending on the environment where the solution will be deployed.
However, if you look at it from the build/release pipeline standpoint… If a solution represents a build artefact, we would not be able to just get that zip file and push it through to the QA/UAT/PROD when every environment needs different values for the environment variables.
Of course we can re-package every time to add environment-specific values, but that breaks the idea of having solution files as build artefacts.
The other option, it seems, would be to set environment variables in the target environment after solution import using some kind of a script, but, then, is it that beneficial to have environment variables in the solution?
There are a few other caveats in the preview, you can read about them in the docs (see that link at the beginning of this post), but might also want to consider a few more:
- Both default value and value attributes are configured to have 2000 max length. It seems environment variables are not meant to store large amounts of data (as in, it would not be “by design” to serialize all your reference data into a json string, pass that string to the target environment through a solution, and de-serialize the json there through a plugin, for instance
- Using environment variables in the classic workflows would be problematic yet (without some kind of custom workflow activity)
With all that said, I think it’s a good thing the product team is moving in that direction, since, in the end, having some kind of solution-aware configuration entity which everyone is using would be really great.
Unless you have other thoughts? Let me know…