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

[matt_bellster]

Thank you Dave.  I often forget to clear the current values in Dev before exporting so that's really helpful information.

[dave-jorgensen]

You're welcome. Bottom line, should never put current values in DEV in the first place - that's what the default value is for

[Anonymous]

Problem with that is: You cant add the environment variable to a canvas app without a current value. It simply doesnt show up. As soon as you add the current value it is displayed.

I would say, set the default to your desired PROD values, current to desired DEV values, remove current values before exporting. Now if you try to edit the app in the prod environment, in studio the datasource will point to whatever the current value was when you added it, but on the play variant it points to the environment variable value(default if there is no current value). 

[dave-jorgensen]

@Anonymous The problem with that approach (other than defying logic) is that it would only work practically in a 2 environment situation, DEV and PROD, but not very practical in 4 environments that all need a different value in the environment as you need to keep removing the values (both default and current) every time you build a package - and then add them back in after you build solution. And during that time, the environment variable (with no values) won't work. I'm actively working with Microsoft to get this straightened out. I'll keep this thread updated on any progress.

[Anonymous]

@dave-jorgensen  any updates on this issue from MS?

[Dave_jorgensen]

Afraid not. I am at least working with the product team on it, but no idea when something different will be ready to roll out to the users

[Anonymous]

@Dave_jorgensen  Thanks for getting back to me.

In my tenant atleast I am now able to add EV's to flows & apps that only have the default value set. I then remove the default value (blank the EV's) before moving the solution to a new environment for the first time(If the EV contains either default or current value you get no prompt when importing). The values chosen on import are placed in the current value table. I can then keep using the default values in the dev environment after, even when updating as the current value will be referenced in the targer environment. So the only catch is that i have to blank the variables when moving to a new environment(to trigger the prompt for current value) and so they will become temporarily unavailable in the dev environment as you mentioned. 

[dave-jorgensen]

Yes. It's what I'm trying to get changed. It makes no sense to have to blank the default value to export/import, because as you've noticed it's the current value that is key where ever you deploy to. Originally too, you just had to remove the current value when exporting. Bottom line, I don't see any reason you've every want to create a current value in DEV and export that. That's exactly the purpose of the default value - here's the default I want in my target environment, but give option to set a current (overriding) value there. Anyway, we shall see what comes of it.

[azdy]

General rule of MS about EV: Remove this value before exporting if it shouldn't be used in other environments

Clear value of EV before exporting!