Securing Data from Public Surveys - comparing two methods

[TanGnar]

I've done a pretty thorough review of the documentation about securing data from public survey123 forms, and I'm left with a question. 

First, I think this question really only applies to surveys published from Connect, given that the web designer does some view creation for you. 

For surveys published from Connect that are intended to be public -- is it preferable to attach the survey form to a view, as described in the blog post here by @IsmaelChivite ?

OR does modifying the source hosted feature layer's settings to only "Add" editing allowed, and "Editors can't see any features, even those they add" provide security to the data? I've seen this referenced, and indeed it appears to prevent any querying of the hosted feature layer. 

I want to make sure I'm not missing anything to make sure publicly submitted data can be secured properly. Thanks!

[ChristopherCounsell]

The web form originally behaved the way Connect does now. When the fieldworker view was introduced, the Survey123 team indicated they would move towards doing this for Connect, but it hasn't seem to have come about for whatever reason.

You could get away with the workflow you described, but I wouldn't recommend it. Always aim to NEVER share the original feature service. It's best practice and will save you a lot of potential headaches. It also won't take much additional time to setup and you seem to be across the behavior which may be the tricky part!

I would recommend:

1. Creating your survey in Survey123 Connect and publishing it, to create the feature service
2. Creating a View Layer for submission (as the web form designer does)
3. Changing the submission URL of your survey from the Hosted Feature Layer, to the submission View Layer
4. If a public survey, set it to 'add' only and disable any ability of users to see the data through the setting you mentioned
5. Create additional views, as required, to share results or complete other workflows. These may have editing settings for internal review groups, or not editable and filtered (i.e. reviewed) for sharing to the public.

The reason you take this extra effort is it's much easier to open/close access to whatever workflows you want, whenever you want it. Have a door (view) for each purpose. No longer accepting submissions? Unshare the view and survey.

It makes it a lot easier to review the door (view) in its context. Imagine someone adds the feature service to a map, to edit the submitted data. They might enable the editing so that they can do this. Now, your public feature service is editable, and the person who enabled it may not have considered the implications of this. Where as if you have items like the below:

• Feature Service (do not share)
• View - Public Submission (shared to the public, allow adds only, no viewing results)
• View - Internal Review (share internal only, for editing results submitted by the public)
• View - Public Share (filtered, share results to the public, do not enable editing)

The purpose and intention can be made clearer through the View titles, metadata, etc. Then managing access is clearer, intentional and easier - you can open/close the doors easily.