Using Environment Variables in Common Data Service

Dynamics 365 now allows configuring of environment variables that makes storing and retrieving  configuration data easy. This has the following advantages:

• Better management of configuration data compared to hard coding and other approaches such as the need for a custom entity to store configuration.
• One place to read configuration from multiple components like Plugins, Canvas App, Flow, PCF etc.
• Migrate as part of solution for the build and release process

The one missing feature of the environment variable is a way to securely store and retrieve sensitive information like API keys, secrets etc.

While it's a good practice to use secure services like Azure Key Vault or some secure mechanism to store and retrieve sensitive information, it might be beneficial in some cases to just have an out of the box solution that we could leverage without additional dependencies.

There are also additional limitations as described here. I personally feel the advantages outweigh the limitations.

In this post we will look at

• Creating an environment variable
• Migrating an environment variable
• Accessing an environment variable

Creating an Environment Variable

We could create the environment variable record easily from the solution or you can also create it from advanced find. The recommended approach would be to use the solution.

Now let's create a variable of type string, we can also create JSON to store multiple values in a single environment variable.

There are two things to keep in mind

• Default Value as mentioned above is the value that will be used when there is no Current Value available in the environment.  This value is stored in the Environment Variable Definition entity.
• Current Value is used to overwrite the default value. This is useful if we want to use unique values between each environments or if the value is subject to change after certain period of time or if you just want to have the flexibility. This value is stored in the Environment Variable Value entity

 For example, let's say we created an environment variable to store our API       URL in Dev, now when we move to a PROD environment we don't want to       use the Dev URL  from the Default/Current Value in DEV but instead create a          Current Value that's unique to PROD.

Now if we look at advanced find we would now see our Variable definition and the default value

Similarly if we look at the Environment variable Value in advanced find we will notice our Current Value associated to the definition record.

At the time of this writing there can be only one current value that can be associated to a definition.

Migrating an Environment Variable

We can migrate an environment variable just by exporting our solution from the source environment and importing it into the target environment. The other approach would be to move the Environment Variable Definition and the Environment Variable Value records preserving the guid between the environments. The better approach would be to move it as a solution.

Note: Make sure to remove the Current Value from the solution when exporting into higher environments as stated below.

Accessing an Environment Variable

Since the environment variables are stored as entity records, we can retrieve them just as we would any other record within CDS, either using Fetch XML or OData query. We just have to make sure we are using the unique schema name to access our value.

Depending on your use case you can target:

• Environment Variable Definition if you do not have a current value for the variable or
• Environment Variable Value if you would always have a current value. For example, in our case something like below.

I'm really excited to use the environment variables, it's a great feature that would help standardize storing the configuration data.