You’re offline. This is a read only version of the page.
Hello,
As per the recent addition of SP lists to be changed as per the environment variables as explained here - https://powerapps.microsoft.com/en-us/blog/announcing-data-source-environment-variables/
The migration process is not working as expected for me at all, I have done as follows:
In the existing app, I have added list connector with data source variables by enabling the app settings for the
Saved working Power apps app, and then removed variable values as explained in the above article
Imported the same solution into different environment with different SP site and list values
However, when I run the application, it still adds values in the site and list which was mentioned in the previous environment. I have re-checked the environment variables into new environments which are all as expected with different SP list and site. Unfortunately it's not changing the functionality for the different list for me..
Can you please help me what's wrong for me in the migration?
Thanks,
@raniasyaana We checked the schema (reference) names in SharePoint and that solved it for us. So, make sure that in both environments the schema names of all columns match exactly. You can find the schema names by going into the list settings, clicking on one of the columns and then observe the URL, for example:
https://mysite.sharepoint.com/sites/MySite/_layouts/15/FldEdit.aspx?List=%7B9F299377%7D&Field=Lock%5Fx002f%5FUnlock
In this case the column has the label "Lock/Unlock", but the schema name is "Lock%5Fx002f%5FUnlock"
Note that the schema name is only created once and cannot be changed afterwards. So it is important to make sure you create the column with the correct name initially.
Even when the column label is changed later to e.g. "Lock" the schema name stays fixed to "Lock%5Fx002f%5FUnlock".
Hope that helps!
hi, I facing the same issues. any solution/workarounds?
Are you using environment variables in your solution for the data sources? I've found that they've started working better since they implemented the setting of the environment variables at the point of importing, before that I would need to set the variables correctly in the DEV environment and then export them.
I also see the same behavior. Variables still point to the old data source after import... i have "sucessfully" recreated that issue in mulitiple solutions... anyone found a sustainable fix?
I also noticed that it seems to be working with the choices fields now.
Haven't tested very much yet though but I deployed a managed solution from DEV to PROD and the choices fields and lists are showing the correct values from the lists in the PROD environmend variables without errors.
However if you go in and edit the app and go to "Data" and look at the lists and press "Edit data" they are still directing you to the DEV-lists.
Changing the authoring version didnt seem to do anything for me though, I was on 3.22022.23 and it was working as described above and changing to .31 did not make it point to the right lists when chosing edit data.
That is not a problem though since the apps seems to be working now without having to go in and replace the data sources every time you deploy.
Hi @WillJay
I have just deployed a managed solution to my test environment and I am glad to say that all the environment variables are correctly pointing to TEST. I do not have to re-add the connections as described in my previous post.
If I go to the Default solution in TEST and open the canvas app, I can still see that the Dataset names are still showing the DEV name but the data is correctly saved to the TEST SPO lists.
This started to work when I have updated the authoring version from 3.22022.23 to 3.22022.31
@WillJay which authoring version are you running?
I will keep testing other solutions to see if the issue with the IsSearchable switching back to false and Combo boxes using the Choices function have been resolved as well. I will update here ASAP.
Can confirm this is still absolutely an issue and doesn't seem to have had any consistent improvement over the last year. Using env variables for ALM with SP lists is unworkable as I effectively have to just thrash around in the target environment, creating unmanaged layers, just making as many changes as I can until - arbitrarily- something will make them work. I've kept track and its a different thing each time (creating unmanaged layer on the app, in the varible it self, saving and publishing a billion times)
So we have to comprimise our ALM to overcome this. Now I have a sol I'm deploying to PROD (obviously will less wiggle room to 'thrash around' in) and I've managed to get it so that when I load the PowerApp in the studio (via the Default solution) it is pointing to the correct list. However playing the same app it continues to point to the old list.
The best bit is that these env var's are brand new to this environment, have never existed in this dataverse pointing to any other list.... so the underlying cause of this issue transports with the solution.
Really poor work undermining the Power Platform ALM forcing us to look towards other solutions for our low-code business apps.
I am still working as before. Load data to collections and refer all components tot the collections.
When changing environment I remove the sources and add them back pointing to the other environment.
This is doable for my 24 connections and new releases every other month and also mainly the reason I have not looked into other options. Just lacking the time for it.
Just wondering if MS has supplied any kind of work around or solution for this yet. We are into 2022 and this has been out for a while now. I've got a ticket with MS and they seem clueless!
#1
WarrenBelz
637
Most Valuable Professional
#2
stampcoin
570
Super User 2025 Season 2
#3
Power Apps 1919
473
Share
Report
All responses (
Answers (