topic Editing survey feature layer in ArcGIS Pro seemingly removed related table connections in ArcGIS Survey123 Questions

Editing survey feature layer in ArcGIS Pro seemingly removed related table connections

ChaseGunnell — Sat, 04 Jul 2026 20:10:15 GMT

This is a really strange issue and I am completely baffled to what's happening here, so hopefully someone can help. I'll be using screenshots in my explanation, some of them from an structurally identical form with a different name.

I have a form with four repeat sets of questions, two of them involve geopoint questions, so the resulting related layer/table set up looks like this:

An earlier version of the form had certain answers hiding a geopoint question without assigning a default location, leading to many points being assigned to null island (0,0). So I needed to relocate a multitude of bugged geopoints to specific coordinates. These geopoints belonged to one of the related layers, rather than the main layer. I figured the easiest way to do this would be in ArcGIS Pro and use the Move To tool.

So I went to the main survey feature layer item page and used the Open in ArcGIS Pro feature. This opened up the feature layer along with all of the related layers and tables in the project. From there I edited the features in the related layer that needed fixing a then selected Save Web Layer.

The points are now fixed and that is reflected on the Survey123 website, which is great. However, there's a really strange issue with the feature layer now.

The related tables no longer appear on the item page for the main feature layer, but they're still there on the _form and _results views.

Additionally, when using the Open in ArcGIS Pro feature, the layer list looks like this:

It duplicates the first two layers and puts them in place of where the related tables would be.

What's really throwing me off is that if I use Export Data on the feature layer item page, the resulting data is back in its original configuration and the tables are there again.

If anyone has an insight on what is going on and if there's anything I could do to fix this, please let me know. I would also appreciate any recommendations anyone has for editing/cleaning survey data in the future.

Thank you very much for any assistance!

Re: Editing survey feature layer in ArcGIS Pro seemingly removed related table connections

TylerGraham2 — Mon, 06 Jul 2026 14:24:53 GMT

Have you tried submitting a new record and seeing if it appears as it should in your feature layer when you run export data? I assume you are using Export Data from the feature layer's AGOL item information page.

Save Web Layer doesn't save edits you make to the data, it saves changes you make to the appearance. It doesn't look like it is supposed to change the source data, just the appearance, so the behavior with the tables missing from the feature layer is strange and maybe worth a bug report to esri.

https://doc.esri.com/en/arcgis-pro/latest/help/sharing/overview/save-a-web-feature-layer.html

When editing a hosted feature service, the updates are usually automatically pushed, unless you turn off some editing settings that auto commit edits (I've found that the auto commit of edits to a feature service is laggy and degrades performance of making edits in Pro). If you do that, then you should be using the Save/Discard edits buttons in the Editing pane when editing your data. That will save changes to the data without modifying appearances or feature service schema.

It is both a blessing and a curse (usually a curse), but schema changes to the main feature service aren't automatically updated to the the _form and _results view layers. I usually encounter it when developing a form and I make major changes and publish it only to have the survey still point to the unchanged _form view which messes everything up. On the flipside, you should be able to export your view data and hopefully get the feature service data in the original schema.

The quickest solution I'd suggest is to download one of your view layers and publish it as a new feature service from Pro and point a survey to that feature service.

If you don't want to make your users download a new survey, go into Survey123 Connect and create a new survey using the Feature Services option, selecting your new feature service as the one to use. In the XLSform, go to the settings sheet and copy the submission_url and the form_id values and paste them into your already published survey and then update the existing survey.

If you don't mind making everyone download a new survey, use the old survey's xlsform and copy and paste the values (make sure you are pasting values by right clicking and selecting Values from the types of pasting you can choose. Otherwise, you'll be clicking pop-up messages until the cows come home. Do that to both the Survey and Choices sheets. Copy the settings too but make sure to leave the form_id and submission_url values alone since those will point to the new feature service. Delete any cells that overhang the pasted areas or those will cause problems. Do the rest of your survey setup and then publish.

Re: Editing survey feature layer in ArcGIS Pro seemingly removed related table connections

ChaseGunnell — Tue, 07 Jul 2026 23:10:41 GMT

Thanks for the information! I wasn't aware that feature service updates are automatically pushed when you save your edits, and that Save Web Layer is meant for updating appearance rather than underlying data (though it seems like it might be bugged). I was under the impression that opening a feature service in ArcGIS Pro created something like a local copy and you would need to re-share/update the layer after making edits.

I submitted some new records via the field app and found that: 1) the exported data still has the original schema w/ tables and incorporates the newly submitted data normally (this is using Export Data from the feature layer's AGOL item page), 2) on the hosted feature layer page, the related layers get updated, but the related tables still don't appear, 3) the feature layer views function normally and new data is incorporated correctly.

I published an identical survey for testing and was able to reproduce the problem by just using Save Web Layer, so I think that's the source of the issue. I tried to alter the schema by adding new questions and changing domain values then republishing, but that did not make the related tables reappear. I'll look into submitting a bug report to Esri.

I'll try your solution that avoids having folks download a new survey. As far as downloading and republishing one of the view layers, I'm wondering what the best way to go about that is; do you suggest using Export Data first to download the data (I assume in FGDB format), and then sharing from Pro? Or accessing the data using Open in ArcGIS Pro on the item page and publishing it as a new feature service from there? I'm not sure what the best practices are for something like this and I'd like to avoid anything that could mess up things like layer and attachment relationships.

Thanks again for your help! I really appreciate it.

Re: Editing survey feature layer in ArcGIS Pro seemingly removed related table connections

TylerGraham2 — Wed, 08 Jul 2026 17:29:42 GMT

Personally, I'd export it to an FGDB and publish it as a new service using Pro. That way you can check to make sure all your relationships are functioning properly. It has been a long time since I've exported data to an FGDB and it used to not maintain the relationships, because it would assign new global IDs but not update the GUIDs in the child tables to point to the correct parent record. You'll want to make sure that isn't the case.

You could also use the ago-assistant to copy the feature service directly. This is definitely faster than downloading and republishing, and if things were working normally this is what I'd do. https://assistant.esri-ps.com/ My concern with that is if you copy the original feature service it might not bring the schema over correctly if it is bugged. If you copy the view layer, I'm not exactly sure what you would get as a result.

Either way you'll need to do some verification that things moved correctly. In the end, the best method is the one that works. 😉

Re: Editing survey feature layer in ArcGIS Pro seemingly removed related table connections

ChaseGunnell — Thu, 09 Jul 2026 22:28:24 GMT

Update: here's the method that worked best for me:

Exporting and downloading the data from a view layer to a FGDB.
Opening the FGDB in ArcGIS Pro and adding the layers and tables to a map
- I did not add the ATTACH and ATTACHREL tables to my project, and relationships seemed to stay maintained anyway
- I did not need to reassign Global IDs nor update GUIDS
Highlight the layers and tables, right-click and select Sharing>Overwrite Web Layer
Navigate to the survey folder and select the original feature layer
Configure your layer settings to match those of the original feature layer (i.e., sharing, editing permissions, etc)
- Pro will prompt to allow assignment of unique numeric IDs for you can publish the layer
Publish the layer—the feature layer is back to its original format and still retains its connections

I tried the method of publishing the FGDB as a new feature service and redirecting the survey to use that one instead, but I ran into the issue of the _form and _results views still being tied to the broken feature service. I was not able to change the source of the views on to the new service (I kept getting errors about geometry types not matching). There also doesn't seem to be a way to recreate views via the Survey123 website. Deleting the views then changing the settings on the Collaborate page didn't recreate the views. I manually recreated the views but still wasn't able to find a way for the Survey123 website to recognize them.

The method I used avoids having to change the submission_url and retains the connections between the views and the feature service. I've been able to submit records and also update the sharing settings on the Survey123 website without any issues so far. Attachment relationships work correctly, and the views function correctly for others who have access to them.

If anyone knows of any issues this method might cause in the future, please let me know. Otherwise, it seems to have done the trick!