Announcing data source environment variables

Applications often require different configuration settings or input parameters when deployed to different environments. Environment variables store the parameter keys and values, which then serve as input to various other application objects.  Because environment variables are solution components, you can transport the references (keys) and change the values when solutions are migrated to other environments. 

Benefits of using data source environment variables: 

1. Provide new parameter values while importing solutions to other environments. 
2. Store configuration for the data sources used in canvas apps and flows.  
   • For example, SharePoint Online site and list parameters can be stored as environment variables; therefore, allowing you to connect to different sites and lists in different environments without needing to modify the apps and flows. 
3. Package and transport your customization and configuration together and manage them in a single location. 
4. One environment variable can be used across many different solution components – whether they are the same type of component or different.  
   • For example, a canvas app and a flow can use the same environment variable. When the value of the environment variable needs to change, you only need to change one value. 
5. Additionally, if you need to retire a data source in production environments, you can simply update the environment variable values with information for the new data source. The apps and flows do not require modification and will start using the new data source. 
6. Supported by Solution Packager and DevOps tools enable continuous integration and continuous delivery (CI/CD). 
7. The environment variables can be unpacked and stored in source control. You may also store different environment variables values files for the separate configuration needed in different environments. Solution Packager can then accept the file corresponding to the environment the solution will be imported to. 
8. Let’s use a simple example:

I use different Power Platform environments for development, QA, and Production. In the development environment, I build a canvas app and flow that connect to a development SharePoint site and list 

Similarly, I have different SharePoint sites and lists for dev, QA, production. When I migrate, the solution containing the apps and flows to QA and Production environments they must connect to the corresponding QA and Production SharePoint lists.

Check the following steps for migrating your solution to another environment.

Step 1: Create my solution and canvas app 

1. Login to Power Apps or Power Automate 
2. Create a new solution 
3. Create a canvas app from the solution 
4. In the canvas app designer enable the setting to Automatically create environment variables when adding data sources 
   • This step is optional if following the approach in 7 – note
5. 
6. Add a data source for SharePoint and select a site, then one or more lists as you ordinarily would. 
7. Now you’ll see a confirmation screen to notify you that environment variables will be created
   • Note: data source environment variables can also be created within the solution interface. You can select pre-existing environment variables when adding a data source to your app by clicking the “Advanced” tab 
8. When you save the data source your app is now connected to SharePoint via two related environment variables. One to hold the site URL and one to hold the list ID (dataset and table parameters) 

Let’s discuss your project

Step 2: Create a cloud flow 

1. Add a button to your app 
2. For the action select Power Automate, then Create a new flow 
3. Set the trigger 
4. Choose an action for SharePoint. I’ll use Create an item for this example. 
5. In the Site address parameter, scroll down and click Enter custom value 
6. Under Dynamic content, you’ll see a list of environment variables to choose from 
7. Select the appropriate site environment variable created when building the canvas app in step 1 
8. Do the same for List name, then save the flow 
9. Your flow is now connected to the same SharePoint site and list and using the same environment variables as your app 

Step 3: Migrate your solution to another environment 

If you want to provide new environment variable values when importing to other environments, it’s important to remove the values from your solution before it’s exported. You do not need to delete them from the environment, however. This way everything will remain connected in the development environment.  

1. Select the SharePoint site environment variable in your solution. In the edit panel, select the ellipsis by Current site, then Remove from this solution 
2. Do the same for the SharePoint list environment variable 
3. Export the solution as managed 
4. Switch to a different environment, then import the solution 
5. You’ll be prompted to select a SharePoint connection (for the connection reference), then can proceed to provide new values for the environment variables 
6. Import the solution and everything will be connected to the new SharePoint site and list. No need to modify or turn on anything! 

Current limitations 

1. SharePoint Online is currently the only data source supported for environment variables of type “data source” within canvas apps. However, the Common Data Service connector will be available soon for when connectivity is required to Data verse environments other than the current environment. Other types of environment variables may be used within canvas apps by retrieving them as you would record data via a Data verse connection. 
2. Using environment variables within triggers in Power Automate is currently only supported for a limited set of connectors. Supported connecters for triggers are SharePoint, Common Data Service, and SQL server. 
3. When environment variable values are changed directly within an environment instead of through an ALM operation like solution import, flows will continue using the previous value until the flow is either saved or turned off and turned on again. 
4. Validation of environment variable values happens within the user interfaces and within the components that use them, but not within Data verse. Therefore, ensure proper values are set if they’re being modified through code. 
5. Power Platform Build Tools tasks are not yet available for managing data source environment variables. However, this does not block their usage within Microsoft provided tooling and within source control systems. 
6. Interacting with environment variables via custom code requires an API call to fetch the values; there is not a cache exposed for 3rd party code to leverage. 
7. When editing a cloud flow, the environment variables are shown in the dynamic content selector under a heading of Parameters but will be under a heading of Environment Variables in the near future. 
8. When editing a cloud flow, the environment variables shown in the dynamic content selector are unfiltered but will be filtered by data type in the future. 
9. If environment variables added in another browser tab, the flow needs to be reopened in the flow designer to refresh the dynamic content selector. 
10. When editing a cloud flow, an environment variable with a label of $authentication might show up that was not defined in the environment. 

If you enjoyed this article, share it with your friends and colleagues and stay tuned for more!