We have built a survey123 that is accessed and edited by users from within a dashboard. The survey allows the user to record two locations: a geoshape that is stored as the records location and a point that is used to populate latitude and longitude reference fields used in geoenrichment. It is important to note the point is not passed through with the record as the bind::esri:fieldType is null. There are no conditions, repeats, calculations, relevants, etc... on either of these geometry fields as they are both required.
Users can create records without issue - the latitude and longitude reference points are populated as expected from a pulldata on the point geometry. The issue comes in, however, when users then go to edit the record from within the dashboard. When a record is selected to be edited, almost all of the record's editable attributes populate - the geoshape question is populated as expected but the geopoint question appears blank, not carrying over the originally submitted point.
I've done a bit of troubleshooting, reviewing blogs and trying the suggestions but without success. Any ideas on why the point is not coming back for editing? Is it because of the null setting in the bind::esri:fieldType?
Some troubleshooting step tried so far:
- I tried defaulting the point location to be the stored latitude and longitude (hoping I could force it back to the originally submitted point when a user goes in to edit) but that did not work - the point was still gone
- I made a separate survey specifically for editing and pointed it at the original survey. In the "editing" version, I removed the pulldata functions from the hidden latitude and longitude field, trying to avoind them getting reset when a record is edited. While it looks like this would work, not having the pulldata functions means that if the customers do update that reference point to a different roadway, we won't be able to capture that information and geoenrich on the new location. The record would be forever stuck having principal route information stored in the attributes which might not be accurate.
We typically try to avoid using repeats because they tend to get finicky - but this is the only other thing I can think of as potentially working. Is losing the second geometry while editing via a webform expected and I missed that somewhere? Or is it because of the null bind::esri:fieldType?
