I’ve blogged previously regarding environment variables, mainly in the context of Power Automate flows and canvas Power Apps. Suffice to say, they are a handy tool to use whenever you introduce an application lifecycle management (ALM) process into your Power Platform project. This is because they provide a straightforward mechanism to alter the behaviour of your applications as you push them out into downstream environments by parameterising aspects of your configuration. For example, you could adjust the destination email address for all Power Automate flows so that notifications will always land where they need to. It’s worth spending some time studying up on them and to consider how you can start to leverage them within your projects.

As great as I think they are, I came across a recent issue with them that I thought I’d touch upon in today’s blog post. Let’s assume a scenario where we want to leverage an environment variable value as part of a model-driven app client-side script using JavaScript. There is no dedicated function that we can call currently to return an environment variable value to us. So instead, we could look to make a straightforward Retrieve request via the Dataverse Web API to get this, similar to the example we can see below:

Xrm.WebApi.retrieveRecord('environmentvariablevalue', '87cd5b2c-b3a2-eb11-b1ac-000d3a4cd2e8', '?$select=value').then(
	function success(result) {
		var value = result.value;
		//TODO: Add code here to process the Environment Variable value
	},
	function (error) {
		Xrm.Navigation.openErrorDialog({ details: error.message, message: 'A problem occurred while retrieving an Environment Variable value. Please contact support.'});
	}
)

This action is possible because all values are stored within the Environment Variable Value table, which we can freely query via multiple mechanisms within Microsoft Dataverse. And, as this example indicates, an assumption is made that the underlying Globally Unique Identifier (GUID) of this row always remains the same, regardless of which environment we are in. A pretty safe assumption, right? Right…? 😅 Well, as I found out when we did a recent deployment involving a similar code snippet above, this GUID will not remain the same, even if you choose to include the current environment variable value as part of your solution. So effectively, this leaves our code snippet above wholly unusable and impractical as a solution. Instead, we need to look at an alternative approach that leverages a RetrieveMultiple request, with an adjusted OData query parameter, to return the environment variable value we want, based on the schema name of the Environment Variable. So assuming this is called jjg_myawesomeev, our code snippet would need to be updated as follows:

Xrm.WebApi.retrieveMultipleRecords('environmentvariablevalue', "?$select=value&$expand=EnvironmentVariableDefinitionId&$filter=(EnvironmentVariableDefinitionId/schemaname eq 'jjg_myawesomeev')").then(
	function success(result) {
		var value = result.entities[0].value;
		//TODO: Add code here to process the Environment Variable value
	},
	function (error) {
		Xrm.Navigation.openErrorDialog({ details: error.message, message: 'A problem occurred while retrieving an Environment Variable value. Please contact support.'});
	}
)

As the schema name of our Environment Variables must always be unique, this is the next best thing available to use to ensure we can retrieve a single value. It is a little bit frustrating, perhaps, but when you understand how Microsoft has set up Environment Variables behind the scenes, it makes sense. Here’s hoping that, in the future, we get a more reliable method made available to us that will handle all of this for us.