Data Source Environment Variables not working for combo boxes based on SharePoint

[mattbell]

Hi
I have migrated a solution between environments.  The solution includes an app whose data is based on a SharePoint library.  There are some combo boxes in a form which were automatically created from the choice fields in the SharePoint datasource.

When I import the solution I update the datasource EV to the correct SharePoint site.  This works correctly in the app apart from on the combo boxes.  I need to delete and re-connecting the datasource and that fixes it.  A refresh doesn't work, and re-connecting the data source using the EV works.

A bit of a nuisance because I obviously don't want to touch the app in the destination environment.

Anyone else experienced this and knows a fix?

Thanks

Matt

[mattbell]

Hence why I posted this.  Now you have a choice - wait an unspecified amount of time for the bug to be fixed, or use my workaround.

[dave-jorgensen]

Ah. You stated in the initial post "I obviously don't want to touch the app in the destination environment", but as you've discovered, that is the only way around the bug.

[capoaus75 · Accepted solution]

This issue seems to have been resolved on my tenancy.

Also there was an issue with "Allow searching" in combo box. If the option was ON, when the solution was imported to a new environment the "Allow searching" option was OFF in the imported canvas app.  From my tests this issue has been resolved as well.  Definitely few steps in the right direction for ALM. Well done Microsoft!!!

[Sonofbob]

For me the connection references update fine in the Canvas App but not environment variables. I have imported solution with the Power Platform CLI using the available commands to generate a settings file, defining all connection reference Ids and Environment variables definitions. The problem is in the canvas apps the data sources and instant flows hold broken references to older environment variable values. I have to manually delete them and then re-add them based on the new environment variables definitions.

What region is your tenancy? I am in the United Kingdom region so is it possible this feature hasn't been fixed in my region yet?

[dave-jorgensen]

As of last time I checked:

PowerApps - data source environment variables used in app don't update if the variable is changed after deploy

Power Automate - data source environment variables in flow update successfully if the variable is changed after deploy

NOTE: for the environment variables to reflect the change in flows, after you change the variable value you need to turn off and then turn on the flow. Values used in flow will continue to be the old value until you do.

[james_hathaway]

I am also experiencing an issue with the Environment Variables - i.e. they don't work at all!

I've not yet even got to the stage of deploying a solution from DEV to PROD, but I am already experiencing an issue with the Environment Variables in the DEV environment.

I have an EV for connection to a SharePoint Document Library - I wanted the option to easily change between a "Documents_DEV" and "Documents_PROD" Document Library (both in the same SharePoint Site).

I created the EV successfully, and when in the PowerApps Studio - the Datasource is indeed pointing to the  list selected in the "Current Value".

However, when I "Play" the published app - it uses the list in the "Default Value", and not the "Current Value".

So, it doesn't even do what it is supposed to do as a basic function (i.e. be a lookup for what value to use)...

... and why have a feature that performs differently in the Studio than it does when Published?

Makes no Sense!

James.

[james_hathaway]

Quick update on the above...

... I can confirm that the "Published" App also completely ignores the List selected in the "Default Value"...

It seems that the app just decides to connect to a Document Library of its own choice.

BOTH the "Current Value" and the "Default Value" are set to the "Documents_DEV" Library, yet when the App is played in published mode, the App points to the "Documents_PROD" Library, 

So, my development/test system seems to be permanently connected to my PROD Document Library, EVEN WHEN THERE IS NO REFERENCE TO THAT LIBRARY.

This is a Huge Security and Data Integrity FAIL, and can potentially cause DISASTERS!

So here's my advice:

DO NOT USE ENVIRONMENT VARIABLES - THEY CAN PERMANENTLY SCREW UP YOUR DATA SOURCES.

James.

[matt_bellster]

This may be a daft question but something which I didn't find very obvious.  Did you connect the data sources using the Advanced tab when connecting to the SharePoint library?

Also, don't use the default values when creating EVs.  They do have a purpose but not one I have come across yet

[james_hathaway]

Hi @matt_bellster ,

Yes - I did indeed connect to the datasource using the advanced tab... (and I clicked advanced to get to the "EV's" rather than select a list)

The most worrying thing is that my app is looking at one datasource when in the Studio, but a different datasource when published...

(and the datasource that the published app is looking at isn't even referenced at all - either in the App OR the environment variable)

James.

[dave-jorgensen]

Default values have a very specific purpose - they just don't work with datasource environment variables. The way it works for everything else is, you set a default value in your DEV environment. You, in all practicality, don't EVER want to create a Current Value in your development environment. When you deploy into your target environment, you set the CURRENT value there (and in practicality never change the default value there).

Power Platform uses Current value if it exists else it uses the Default value (with everything other than data sources, which are just plain broken / buggy in PowerApps but fine in Power Automate).

The idea then is, when you do subsequent deployments, since there is no Current Value in your solution it doesn't overwrite the Current Value in the target environment and therefore they "persist" for that environment. It's why you never want a Current Value in your DEV environment (and it would be great if that was disabled, to prevent users from doing it), because if you have a Current Value in your solution then that gets deployed to target and overwrites the Environment-specific value. That defeats the whole purpose of environment variables, if you deploy / overwrite the Current Value.