Select to view content in your preferred language

Public Form with Group Editing

907
4
09-12-2022 01:37 PM
DerekKonofalski
Frequent Contributor

I've read all the docs about securing Survey123 forms that collect public information ("Limiting Access to Public Survey123 Results" and https://community.esri.com/t5/arcgis-survey123-blog/securing-data-in-public-surveys-survey123-web/ba...). What those documents don't address is a situation like ours where we need to collect info from the public but also need our group to be able to update and edit those forms (either by the mode=edit URL parameter or through the Survey123 Data tab).

Based on what I'd read in the documents, I thought that we could take the _stakeholder view and enable editing on that and only share it with the group needing to edit it. That didn't work and we still get notified that we can't edit submissions from other users. I'm hesitant to edit the Settings on the main Survey layer or the _fieldworker layer, though, because those docs seem to suggest that enabling editing on either layer will expose that data publicly, which we definitely don't want.

What are the proper settings for the various layers (Survey layer, _fieldworker, and _stakeholder) to allow only a specific group to edit the information submitted by anonymous/public users without exposing the entries to the public?

0 Kudos
4 Replies
MichelleWilliamsERM
Frequent Contributor

This post excites my brain! I love a significant challenge.

Have you tried making one hosted service and then creating a new survey just for the public linking to the original hosted service and one for your QC team?

You mentioned that you take the stakeholder view and turn on editing. Below it talks about the stakeholder version being read-only. That might be the problem.

Fieldworker:

The fieldworker is used to manage permissions for submission to the survey as a non-owner. So if you'd like to modify whether a user can add/update, just add, or just update surveys, you would manage those permissions through the hosted view.

Here is where things get a little tricky: The fieldworker view only gets generated if you published your survey from the Survey123 website. If you published from Survey123 Connect, all permissions for submission are simply managed under the main feature service, and the fieldworker view is never created.

Stakeholder:

The stakeholder view is used to manage permissions for viewing the survey as a non-owner. So when any user other than the owner of the survey views the Data tab of the Survey123 website, the stakeholder view is being queried from ArcGIS Online to display the map on the site. So permissions can be filtered or managed from this view to dictate how/what the users see on the Data tab.

Will your edit team use Survey123, a web app, or both?

If you need more help I'm free after 5 pm PST

(1) Michelle (Monte) Williams | LinkedIn

DerekKonofalski
Frequent Contributor

Thanks, @MichelleWilliamsERM. Luckily, this particular survey *was* published with the Survey123 website because the team may need to edit the survey questions in the future. We also have a Microsoft Power Automate flow that's triggered by submissions. Here are some answers to your questions. Hopefully this will help clarify things.


Have you tried making one hosted service and then creating a new survey just for the public linking to the original hosted service and one for your QC team?


I have not. The public doesn't need to see the survey results at all. We only need to be able to accept submissions anonymously/publicly. The issue seems to be that our teams need to be able to edit the responses (and potentially fill in any missing information on follow-up) and then re-submit that particular response. In the past, we've done that right from within the Survey123 tool (Data tab) or by dynamically generating URLs with the "mode=edit&globalId=xxxx" parameters but the surveys themselves have never been public/anonymous (or they were fully public with no sensitive info so no worry about sharing that data).

As far as the distinction between fieldworker and stakeholder, I think this is the crux of my problem that I can't seem to solve. We did publish through Survey123 web so I do have the _fieldworker layer but, based on my readings from those docs, allowing editing on that layer would also allow *anyone* to view/edit/update the entries if they were able to figure out the globalId parameter for an entry. This is the part that I can't have. Right now, our data doesn't include any of that sensitive info but we're looking to add some fields/questions that may contain information we don't want publicly available. Changing the sharing settings to only share with our group, though, seems to disable the ability for anonymous users to submit to the Survey. It's almost like a catch-22 and that's what I thought the _stakeholder view was for but, as you stated, I'm pretty sure that layer is read-only. That's helpful for reviewing the submissions but does nothing for when we have to update/add information to them.

As for your last question, we'll only ever be editing/updating these via Survey123's web app (under the Data tab) or via the URLs with parameters, as mentioned above. Hopefully that helps rather than harms our situation.

Any help you can provide would be great. I've reached out directly thanks to your link. 🙂

0 Kudos
MichelleWilliamsERM
Frequent Contributor

Survey123 Connect is my superpower, so I'm sending you to @Ismael (you'll be in good hands with him.)

DerekKonofalski
Frequent Contributor

I sent Ismael a message a few weeks ago and never got a response so hopefully your superpowers extend farther than mine.  😛

His article is the one that got me to this point to begin with so he's definitely the one with the answers.

0 Kudos