#PowerPlatformTip 61: 'Power of Environment Variables'
TL;DR: Replace hardcoded values with environment variables so the same solution moves across Dev, Test, and Prod without editing app or flow logic.
💡 Challenge
Hardcoding values in apps and flows makes them inflexible, difficult to manage, and cumbersome to migrate across environments.
✅ Solution
Use Environment Variables in Power Apps and Power Automate to externalize configuration, enabling portability, centralized management, and flexibility without modifying app or flow code.
🔧 How It’s Done
1. Create the environment variables
🔸 In make.powerapps.com, open your solution and select New > More > Environment variable.
🔸 Enter a display name and pick the data type: Text, Decimal number, Two options (Yes/No), JSON, Data source (for example a SharePoint site or list) or Secret (stored in Azure Key Vault).
🔸 Set a Default Value if the variable should work everywhere without extra input. Leave the Current Value for the environment-specific value.
2. Use them in cloud flows
🔸 Open a flow that lives in the same solution. Environment variables appear in the dynamic content panel under Environment variables and can be used in any action input, for example as Site Address and List Name of a SharePoint action.
3. Use them in canvas apps
🔸 Data source variables connect the app to a SharePoint site and list per environment. Turn on Automatically create environment variables when adding data sources in the app settings (General tab), then add the data source, and the app creates the variables for you.
🔸 Text, number or JSON values are stored in Dataverse tables. Tip 105 below shows how to read them in a canvas app.
4. Set values per environment on import
🔸 Before exporting, remove the current value from the solution (Current Value > … > Remove from this solution), so it stays in Dev only.
🔸 During Import solution (or a pipeline deployment) Power Platform asks for every variable without default or current value. Enter the Test or Prod value there.
🔸 After changing a value, it can take up to an hour until all apps and flows use it.
🗄️ Under the hood: two Dataverse tables
An environment variable is two rows in Dataverse, both readable through the Web API:
🔸 environmentvariabledefinition holds schemaname (publisher prefix plus name, e.g. contoso_SharePointSite), displayname, type (100000000 String, 100000001 Number, 100000002 Boolean, 100000003 JSON, 100000004 Data Source, 100000005 Secret) and defaultvalue. This row travels with the solution.
🔸 environmentvariablevalue holds the current value in value and points to the definition. It is one row per definition and environment: creating a second value row for the same definition was rejected with Cannot complete the creation of EnvironmentVariableValue because it violates a database constraint ... Please delete the existing record or use update.
One call shows both sides together:
1
2
3
GET .../api/data/v9.2/environmentvariabledefinitions
?$select=schemaname,displayname,type,defaultvalue
&$expand=environmentvariabledefinition_environmentvariablevalue($select=value)
Definitions with an empty environmentvariabledefinition_environmentvariablevalue array have no current value in this environment and fall back to defaultvalue; definitions with a defaultvalue of null and a value row rely entirely on the current value.
What a flow stores. In the flow definition (workflow.clientdata) the variable shows up as a parameter named <display name> (<schemaname>), e.g. SaveFormTriggerURL (contoso_SaveFormTriggerURL), with a defaultValue that matches the value row at the time the flow was saved. The flow resolves it by schemaname, which is why renaming the display name later is harmless and changing the schema name is not.
Create, update, delete through the API. POST environmentvariabledefinitions with schemaname, displayname, type and defaultvalue created a definition; POST environmentvariablevalues with value and EnvironmentVariableDefinitionId@odata.bind created its value row; PATCH environmentvariablevalues(<id>) with {"value": "..."} changed the current value. Both rows landed in the environment’s Active layer (solutionid of the solution Active), not in a named solution, so for anything you want to deploy, create the definition in your solution in the maker portal and use the API only for value updates. Deleting the definition also deleted its value row in the same call.
🎉 Result
Your apps and flows become environment-agnostic, easily configurable, and maintainable, reducing deployment errors and enhancing solution lifecycle management.
🌟 Key Advantages
🔸 Improved portability: move solutions seamlessly across environments
🔸 Enhanced manageability: centralize configuration for easier maintenance
🔸 Greater flexibility: update settings on the fly without altering code
⚠️ Good to Know
🔸 Dataverse required: environment variables are solution components, so the environment needs Dataverse. A premium licence is not required to use them in apps and flows, only if you read them with the Dataverse connector like normal records.
🔸 Limits: a value can hold up to 2,000 characters.
🔸 Reserved names: don’t name a variable $authentication or $connection, flows using them can’t be saved.
🛠️ FAQ
1. What are environment variables in Power Platform?
Solution components that store configuration (URLs, IDs, site and list references, JSON settings, secrets) outside your apps and flows, with a different value in each environment.
2. Can I update a value without changing my app or flow?
Yes. Change the current value in the target environment. Apps and flows pick it up without being edited, it can take up to an hour until the new value is used everywhere.
3. Why are there a default value and a current value?
They live in different tables. The default value is a column on environmentvariabledefinition and ships with the solution; the current value is a separate environmentvariablevalue row, one per environment, and only exists once somebody set it. If the value row is missing, the default applies. Updating the current value is a PATCH on the value row and never touches the definition.
4. Why can’t I see the value of a variable from a managed solution?
The value is an unmanaged customization. Open the variable from the Default solution to see and change it.
🔗 Related Tips
🔸 #PowerPlatformTip 105: ‘PowerApps, EnvironmentVariables Without Premium’ - read these same environment variables directly from a canvas app without a premium connector.
🔸 #PowerPlatformTip 40: ‘Delete Apps / Flows’ - another solution-based technique worth knowing once your configuration lives in solutions.
This tip is by Marcel Lehmann, Microsoft MVP (Business Applications) and founder of the Power Platform Academy – live Power Platform workshops, free or CHF 49. Join the workshop waitlist to get notified about new dates. For companies that want this implemented for them, see KMUpower – Power Platform consulting & automation for SMEs (DACH).