I have a survey meant to collect information about existing features so we can update our data for accuracy. I have a public web map pop-up that accesses the survey via the GlobalID. Initially I had the survey set up to update existing records but since it needs to be publicly accessible, I created a related table to house that information instead. I am now having problems configuring the settings and URL parameter to properly work in collecting information within that related table and need some help.
Now that the sharing setting is add-only, I cannot use the mode=edit URL parameter. Other solutions or using the mode=view parameter results in either of the two issues: You do not have permission to view this survey record. OR Editing is not possible because the record specified by the globalId parameter cannot be accessed.
When I had the sharing set to allow updates/editing, I was able to test out submissions. However, even then the issue there was that if someone requests an update to a feature that already has existing related records, they will see those existing records in the survey web app (web browser) which is not ideal.
Is this workflow even possible? I would like for individuals to be able to just add related records associated with a specific feature. I do have calculations set up so that it brings in existing attributes into the related record, but there wouldn't be any editing or overwriting of existing data. My review process is all set up, the only issue I am having is exposing that survey to the public.
Solved! Go to Solution.
Hi @Tiff-Maps
The Survey123 web app has limited support for editing repeats, and you are running into one of them. In short. The default behavior of the web app is such that it will display all related records and allow you to delete/add/update them according to the settings in your feature layer.
If you disable query capabilities by making the layer add-only, the repeat will fail to load. If you enable queries to let the repeat load, you could disable updates and deletes, but respondents could still look at other related records.
If using the Survey123 mobile app (Inbox), the above limitations do not exist, because you can control what related records are loaded (using a where filter) and even what permissions are set in the repeat (allowUpdates=false, for example). There are more details about this in the Repeats in the Inbox section of this blog. It does not seem like using the mobile app is an option in your case.
In short, I think that you have reached a limit. I am copying here my colleague @ZhifangWang in case he can think of any other options or make a correction.
As a workaround, I am thinking that you could have the popup launch a survey that ONLY works with the related record. That is, instead of loading a survey with a repeat, you load a survey that targets the repeat related table directly. You will need to pass the GlobalID field to populate the parentGlobalID field in the related record and open the survey in normal mode (not in edit mode). To do that you will need to:
When your new survey is launched, all the respondent will see is a survey to add comments or new info into the record. Submit and go. No options to see anything other people added.
I hope this makes sense.
Hi @Tiff-Maps
The Survey123 web app has limited support for editing repeats, and you are running into one of them. In short. The default behavior of the web app is such that it will display all related records and allow you to delete/add/update them according to the settings in your feature layer.
If you disable query capabilities by making the layer add-only, the repeat will fail to load. If you enable queries to let the repeat load, you could disable updates and deletes, but respondents could still look at other related records.
If using the Survey123 mobile app (Inbox), the above limitations do not exist, because you can control what related records are loaded (using a where filter) and even what permissions are set in the repeat (allowUpdates=false, for example). There are more details about this in the Repeats in the Inbox section of this blog. It does not seem like using the mobile app is an option in your case.
In short, I think that you have reached a limit. I am copying here my colleague @ZhifangWang in case he can think of any other options or make a correction.
As a workaround, I am thinking that you could have the popup launch a survey that ONLY works with the related record. That is, instead of loading a survey with a repeat, you load a survey that targets the repeat related table directly. You will need to pass the GlobalID field to populate the parentGlobalID field in the related record and open the survey in normal mode (not in edit mode). To do that you will need to:
When your new survey is launched, all the respondent will see is a survey to add comments or new info into the record. Submit and go. No options to see anything other people added.
I hope this makes sense.
Thank you @IsmaelChivite for your response! Really appreciate it. I can definitely see your suggestion as a viable solution.
My only question is whether I can pull information from the feature layer and reference it in the new survey. For example, Name, Address, City, and State are fields from the hosted layer I am displaying to the user as well as populating that same information in the related record. Right now it uses the calculation parameter to calculate the layer fields in the repeat fields. I know this may not be necessary data management-wise, but is something I would prefer just as a quality check. It is also helpful to show the information to the submitter so they have it as reference.
I believe I have tried something similar using the autocomplete search appearance but I recall not really being able to achieve what I was looking to do. Is there a way to do this that I am just not aware of? That would be the only missing link for me to work towards the solution you suggested!
I think it is doable. Simply add the extra fields you need into the related table and populate them using URL parameters. You can send this info via the link you include in the popup.
In the original survey you can calculate these extra fields as you already do. In the second survey, the one pointing direcltyi to your related table, these fields will not be calculated. Instead, you populate them with URL parameters when the form is loaded.
I think I've got it all set up! Thank you SO much. I am ecstatic that I was able to resolve this issue and sustain a very similar workflow!