Seeking Advice on Secure Editing for Survey123 Submissions

Question

Hi everyone,

I’m looking for some expert advice regarding Survey123.

We use a Survey123 form to collect requests from our clients. These clients are not AGOL users and don’t have AGOL accounts. As a result, the form and its associated layer are shared publicly, and clients access the form via a web link and submit responses anonymously.

The challenge: I need to allow clients to access and edit their submissions when they need to make amendments (which happens frequently). I understand that this can be done by directing them to their specific submission using a URL link, as explained by @Ismael in Survey123 Tricks of the Trade: Editing records in a web form

However, enabling this requires making the layer “read access enabled,” which would expose all survey responses. This makes me uncomfortable because the data is sensitive. Our organization’s website is secured against anonymous access, but I’m concerned that someone with bad intentions could extract the form ID from the URL, search for it on ArcGIS.com, and potentially access the underlying layers.

Question: Is there any way to allow anonymous users to edit their own submissions while still protecting the rest of the data? Has anyone implemented a secure approach for this scenario?

Thanks in advance for any insights!

Ken

MobiusSnake · Answer

Editing their previous responses directly in the form, anonymously, without exposing records to everyone ... I don't think so.  However, there may be a way you could allow them to append updates to an existing anonymous submission, then merge the results on the back end.

Disclaimer:  This is ugly.  So ugly I'm kind of hesitating to click the Reply button.

Assuming the form includes an email address, use a webhook or a scheduled notebook to pick up the initial submission and email the user a report containing all of the questions and their answers for review.  In the email, include a link to a second form (instructing them to open it if they need to make revisions), and include the first submission's Global ID as part of the link, so it'll be passed into the second form.

In the second form, store the first submission's Global ID as a hidden question with a GUID data type.  This second form could have the same questions as the original form, but only instruct the users to fill out the questions that were wrong in the report they received, leaving the rest empty.  The second form would point to a different hosted feature layer view than the original form, but its schema would be similar (except with a new GUID field, and maybe a subset of questions).

Pick up the second form's submission using a second webhook or a scheduled notebook, and use some Python to merge the second record into the first, based on the GUID passed into the second form and the original record's Global ID.  (Detect values that are non-empty, apply updates to the original, overwriting a subset of the original feature's attribute values.)  Then delete the second submission.

I don't think this would be appropriate if you have long text answers and the user just needs to fix a typo, and it'd get really complicated if you have repeats, or complex logic in the form for turning questions visible/invisible.  But it might work for a fairly simple form.

RTPL_AU · Answer

Hi @KenBouchard

I'm not aware of a free method to get this done. Commented in part to see other responses.

As you mention clients, do they spend enough so you can accommodate an AGOL license as part of your offering? (in real terms a Contributor license is equivalent to ~3hours billed over a year).
If client tenure is short term you can spread the cost over a few clients so the cost is pretty much trivial.

Enable SSO for AGOL and issue an Azure etc credential to your client. That also allows you to incorporate them into your org's off-boarding processes, security auditing, etc.

There is no way that I will share client data to an open endpoint, even if it is an obscure URL. You don't want to be in the news as the "third party supplier that had left the data open to public access by not protecting a cloud storage location".