Power Platform – Managing data sources with environment variables

SharePoint and Power Platform are a great combination for many use cases. However, I have always been bothered by the fact with this combo you cannot practically operate in separate test and production environments. I have already written a post on this subject in the past.

The cause of this problem is understandable.

Power Apps and Flows are connected to SharePoint using a connector. The connector is not aware of which site and which of its list will be utilized. This information is defined within Power Apps and Flow during their creation.

When the solution is moved to another environment in a later phase, this information has to be corrected. Each time the solution is moved.

There has been many ways to deal with this problem, but all of them have been more or less bad. And each of them involves manual steps.

The solution – Environment variables

The problem has now been solved. Finally, we can move a solution that uses SharePoint from one environment to another, without fixing Power Apps and Flow each time.

This is achieved with a new datasource-type environment variable.

The solution now looks like this with the two environments.

Let’s see how this is achieved in practice. At the same time, we will find out whether there are any shortcomings in this promising feature.

Example – Issues

Let’s use Power Apps + Flow combination that utilizes issues stored in a SharePoint list as an example.

Saving the data (SharePoint list)

Create an Issues list in the development/test site called Timo Dev Env, and add a few test rows of data to it.

An identical Issues list is then created in the separate production site called Timo Prod Env. The easiest way to do this is to copy the list from the development/test site.

A few issues are also created in the production environment.

Solution and environment variables

So that the whole solution is movable between environments, the development is done within a solution. Let’s create a solution called Issues Demo in the development environment.

Next, the magic begins.

A new environment variable is created where we will store the SharePoint site we use in this environment.

Let’s give the environment variable a name (1), select the data source (2) as the type, SharePoint (3) as the connector, the existing SharePoint connection (4) as the connection, and the site (5) as the parameter type.

Lastly, the value of the variable in this environment is stated (6, Current site value ). The value is selected from the list. Easy!

Let’s create another environment variable, where we will store the SharePoint list we use in this environment.

Same steps as with the site, but this time the parameter type is selected as a list (1). After this, we are able to choose from which site the list can be found in (the site refers to the variable we just created).

Finally, the value of the variable in this environment is selected (Current list value, 3). That is, what list do we use.

Our environment variables are now ready!

Using variables in Power Apps

Next, we will create a Power Apps that uses the Issues list as the data source.

Create new (Canvas) Power Apps from New -> App -> Canvas App – Tablet form factor.

Add a new data source (SharePoint) to Power Apps as usual. However, we don’t choose which site and its list we want to use, but rather go to the Advanced tab.

From there, we can find the environment variable we just created called Issues SharePoint Site.

Select this, then choose which list of the selected site to use. We again go to the Advanced tab and select the variable Issues SharePoint List instead of a regular list.

A list added using an environment variable looks and works in Power Apps just like a list added as a data source in the traditional way.

Finally, we add a gallery that displays the rows in the Issues list.

And we are done! Let’s save and publish.

Using variables in Flow

We want to send a message to Teams whenever a new issue is added. Let’s create a new Flow inside the solution package for this purpose.

Yes! We can also utilize environment variables in the triggers In addition to Flow’s basic functions.

The values ​​of the variables can be found under the heading Parameters, but that will be changed to Environment Variables.

We want to send a message about the issues added in the test environment to the Team inside that environment, and do the same for issues created in the production.

Let’s add new environment variables for the team to be used (Issues Team Id) and for the channel (Issues Team Channel Id).

And

The created environment variables can now be found among the parameters.

Now we have Flow, which is easily transferable from one environment to another.

Compared to the previous way, there are two significant differences

1. The Trigger site and list can be read from the parameters
2. SharePoint list schema can be used with the parameters in Flow. That is, Flow knows which fields are in the SharePoint list behind the parameters.

First installation in the production environment

Before the first transfer to the production environment, the value of each environment variable must be removed from the solution package to be transferred. Otherwise, the values ​​bound to the variables will get moved into the target environment and everything is ruined.

Let’s edit each environment variable and select Remove from this solution in the current value.

Once the variables have been cleaned, we can start the export of the solution package.

The end result is a zip package.

Now let’s move to the target environment and import the solution package there.

During the first import, the connections to be used in the target environment are selected.

After this, we will give values to the environment variables. In practice, we will choose which SharePoint site and list to use in this environment.

Does it work?

Let’s open the Power Apps in the production environment, that was imported from the development environment. The gallery displays the issues from the SharePoint list we used in production. Great!

And when a new row is added to the production issues list, Flow starts as expected.

Bringing a new version into production

Let’s try the final test. What happens when we make changes in the test environment, and import the new package into production?

Let’s modify the flow a bit.

And do the same for Power Apps.

Let’s export the solution package from the test environment without adjusting any variables or connections.

When we open the Power Apps in the production environment, everything works nicely.

But what about Flow?

Everything is ready!

And when importing, there is no need to specify at any point which site and list should be used.

Environment variables are absolutely awesome!

The feature utilizes Dataverse, so both the source and target environments must have it. However, the use of environment variables does not require separate Power Apps or Flow licenses.