Cloning survey items from on-prem Portal to Arcgis.com

[derekwmiller]

Is cloning surveys from on-prem portal to Arcgis.com supported?

I can successfully clone the survey folder and all items from portal - arcgis.com, but survey123 does not recognize the survey. Survey123 errors with 'The survey does not exist or is not accessible.'

[Zachary-Sutherby]

Hello @derekwmiller, cloning from an internal Enterprise organization to ArcGIS Online is supported. Are you using a registered feature service with your survey (is the service pointing to an enterprise geodatabase)? On the item details page of the Form item created in ArcGIS Online there will be a Layers section halfway down the page. In that Layers section does it have the link to the hosted feature layer in your ArcGIS Online organization?

[Zachary-Sutherby]

Troubleshooting sample script: clone_troubleshooting.zip

[derekwmiller]

Hi @Zachary-Sutherby. I'm not using a registered feature service. It's a hosted feature service. Post clone, there is a layer section with a link to the feature service but the service URL requests a token (which is odd, to say the least). Note that I tested and successfully cloned feature services when I first encountered the issue with the surveys.

[Zachary-Sutherby]

Hello @derekwmiller,

I think I've narrowed down the issue and have added a fix in the notebook that's working on my end.

Here is a zip file with the updated notebook containing the fix. clone_surveys_from_one_organization_to_another.zip

If you test on your end do you see the same error message?

[derekwmiller]

thanks @Zachary-Sutherby. I'll test and report back

[derekwmiller]

@Zachary-Sutherby I can't find your fix in that new .ipynb. The actionable cloning action, item gathering from source, etc. looks to be the same as in the repo. What am I missing?

[derekwmiller]

@Zachary-Sutherby also, just to be clear, there is no data in the survey being cloned. I did notice you're querying the cloned feature services and returning feature counts

[derekwmiller]

@Zachary-Sutherby same error. I honestly didn't see any functional difference between the ipynb you shared and the code that I had been using that produced the error.

I put together a quick test based off your new notebook (attached) and reproduced the error. Don't be shy pointing out my user error if you one.
share.zip

[Zachary-Sutherby]

Hello @derekwmiller when I was testing on my end I was seeing that the name of the survey Form item in the back end configuration JSON was different between ArcGIS Enterprise and ArcGIS Online. What I had done in the notebook above was add a couple lines of code that downloaded the survey form item after cloning and made sure the name and file extension of the form item was correct. I then took that downloaded form item and updated the cloned item with the correct file name which worked on my end.

In your scenario I think the link between the survey form item and the feature service it's supposed to be pointing to has somehow been broken. Below I have attached a notebook that will check if that link has been broken. If the link is broken the notebook fixes the link and then does the workflow that the previous notebook does in order to ensure the back end JSON is updated correctly.

add_survey_relationship.zip

As for bringing over the data the notebook discusses the clone_items() method has an optional copy_data argument. By default this is set to True which will copy over the data, otherwise if you don't want the data you can set that argument to false. In my testing I was testing with surveys that contained no data.

[derekwmiller]

Got it. I had dismissed that section following the clone command thinking "Well I don't need to download the thing". I'll give this a shot @Zachary-Sutherby and let you know. Thanks for all your effort to this point.

[derekwmiller]

Hi @Zachary-Sutherby
The link between the survey form item and the feature service was not broken.
The download >> update workflow has resolved the issue. Apologies for missing that bit yesterday.

SO -- this is working, currently. Thank you very much.

Couple of questions for you:

1. Is this going to be logged as a bug and fixed as appropriate? Or, is this download >> update workflow going to be necessary for the foreseeable?
2. Is the configuration JSON in which you noticed the discrepancy between names something that is exposed via the Python API or otherwise discoverable to users? Or Esri eyes only?

[Zachary-Sutherby]

This issue has been logged as BUG-000141004 and a workaround has been added to the notebook that downloads the survey from the target organization and then immediately updates it using the zip file downloaded.