Showing results for 
Search instead for 
Did you mean: 

Move or Copy a SharePoint list PowerApps Custom Form

It would be nice to be able to create a SharePoint list PowerApps Custom Form in one site or list (e.g. development) and then be able to move it to another site or list (e,g, production). This would help with development and teting of new and updated forms before they are released to the production. This could also help with the reuse of form designs, so a person isn't always recreating the wheel.

Status: Under Review
Regular Visitor

For anyone looking for a cost effective replacement of InfoPath with the ability to export a form configuration including SharePoint lists structure, form layout, workflow and logic you should consider Sintel Forms For SharePoint. It's completely free for up to 2 forms.


Eoin McMahon - Sintel

Super User

Hi all,

Just so you know, I have experienced the replication of a SharePoint form customized with PowerApps from one site collection to another and here are a few tips to know...


  1. Firstly, one should know that the lists (the one I customized with PowerApps and the 3 other lists used as datasources) in my destination site collection are EXACTLY the same as the ones in my source collection (I used PnP Provisioning to replicate the site columns, content types and lists from the source site coll. to the destination site coll.)
  2. Then, following @SPRohit's procedure, I noticed that not only you should modify the <long number>.json file located in the folder named Microsoft.PowerApps\apps\<long number folder>, but you should also modify the manifest.json file located at the root level of the package generated from PowerApps. Indeed, the DisplayName properties (there are two) in the manfiest.json file must be modified to meet the one in the <long number>.json file (beware: the DisplayName property value cannot hold more than 64 characters <- lost 2 hours on this!). Also keep in mind that the DisplayName in those files must be different at each import on the destination site collection.
  3. Also, in the <long number>.json file, replacing the GUIDs of the datasources with the ones for the destination site collection did not do the thing. Once I opened the form in the destination site collection in PowerApps and looked at the datasources, they would still point to the source site collection ones. So, in the destination site collection, when in PowerApps on the form, just remove all data sources and add them again from the correct destination site collection url.
  4. Then everything would work fine.

Has anyone noticed these problems as well ?

Regular Visitor

@R3dKap I think this is a classic example of where for a lot of organisations using SP list PowerApps isn't feasible.


With the new modern IA guidance where everything is a site collection when you have common site types if you need a SP list PowerApp having to perform these steps everytime simply isn't practical.


I think they will/plan to introduce some API endpoints for managing these things but its still a show stopper for me.

Kudo Kingpin

Until this feature is implemented - you can try out this approach:

- Export your app that points to the SharePoint envrionment #1

- Convert exported package using

- Import converted package to the Environment #2

Not applicable

@DenisMolodtsov- Receiving the following error when running the script:

ForEach-Object : The term 'resources[$i].newId' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At C:\FlowPowerAppsMigrator\ConvertPackage.ps1:20 char:14
+     $files | ForEach-Object {
+              ~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (resources[$i].newId:String) [ForEach-Object], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.ForEachObjectCommand

Kudo Kingpin

@Anonymous Can you create an issue on GitHub, please? I can have a look at it.

Not applicable

This is must to have feature when we customize form in multiple environment like DEV/QA/PROD

Super User

@Anonymous : I had the exact same issue today and it was due to a list which existed in my source environnement but not in my target environnement.

To quickly identify which one is causing the problem, just modify the ConvertPackages.ps1 file as shown below:


        for($i=0;$i -lt $resources.Count;$i++){
            if([System.String]::IsNullOrEmpty($resources[$i].newId) -eq $false){
                Write-Host Converting $resources[$i].resource ... -NoNewline <-- Add this line
                (Get-Content $_.FullName) -replace $resources[$i].oldId, $resources[$i].newId | Set-Content $_.FullName
                Write-Host Done. -ForegroundColor Green <-- Add this line
                Write-host Destination GUID not found. Make sure the data source exists: $(resources[$i].newId)


The next list following the last good conversion written to the host (thanks to the code up here) in the resourceMapping.csv file will be the one... 🙂

Resolver I

Wow! This worked beautifully across site collections! Thank you so much!


Advocate I

@Audrie-MSFT . Still no trace of this feature on the Planned Features list ( Do you have any updates since last summer since that's when this idea got changed to "Planned"?