Sign-in Issue/Bug for Survey123 Users

[JoeMarshall-Mills7]

We have recently set up a Survey123 form (using the web version) for one of our Viewer roles. We have gone down this route as they are able to edit their own submissions, with the correct settings (avoiding the need for them to be a Editor in any capacity). However, we have clear issues we have had to overcome when trying to achieve this;

1)  As you need to set the form to Public for a Viewer to submit (this in itself needs changing urgently and I am aware of other comments/posts regarding this), I have worked around this by adding a field that checks the submitter's username. If it doesn't match an allow list of users set by myself (e.g. someone who is anonymous), then it will appear blank and not allow them to submit. 

2) Because of this field I have added, it requires the form to recognise a logged in user which is clear by the options bar appearing at the top of the form with your name/username. However, with testing, the user accessing the form via our organisational content does not show this options bar and therefore does not reconise a signed in user. 

With that being said, if the user logs into Survey123 directly (where they can then access the form and its related data) and proceed to open the link to the form itself after doing this then the options bar appears and shows them as being signed in, making the username check field operate correctly. 

There are clear issues to overcome for Viewer lisences working with Survey123 as a whole but specifically there is a bug with users accessing forms via organisational content (I have mentioned Viewers here but this also applied to another Admin account we tested). 

Has anyone else experienced this issue? How can this be raised as a bug with esri? 

[ChristopherCounsell]

What you are doing is an anti workflow. The answer is to have public surveys (no licence) or non-public surveys (field worker licence). I don't envisage a world where ESRI would recognise this as an issue. You are effectively circumventing their security and licensing models.

I cannot recommend sharing surveys and feature editing publicly.

Taking the workaround leaves you exposed for moments like this when things don't work as expected or designed.

I know this is not the advice you were hoping to hear but hope it is helpful for your consideration.

I would recommend considering setting up your survey for secure data collection (publicly shared, adds only) and then securing the submissions / follow ups. E.g.

• Survey form with point + repeat
• Share survey View with editing public, users can't see features, allow adds only 
• Create another view (no editing) and share it to your Viewers. Use the pop-ups to launch another survey form targeting the related table only (collecting additional data).

You can use views, defaults, python notebooks, emails and webhooks to control the data flow and updates. E.g. instead of a map, it could be an email with a unique link for user submissions to follow up.

This expands your options within the realm of supported workflows.

[JoeMarshall-Mills7]

Good morning.

Appreciate the response and couldn't agree more with you in terms of our current workflow. It feels long winded to do this. To confirm, our Feature Layer is not shared publicly so should not be exposed. Only the default provided Form and Results views are (editing enabled on the Form view only). I agree, ideally the Form view would be shared organisationally only as this does not need to be public. 

Just to give some more context, this is a member of staff who does not need a Creator lisence as they are only performing this kind of operation for a month of the year (if at all). I need to double check but as a third sector organisation we also do not have access to Field Worker. So having them stay as a Viewer helps us keep costs down while undertake the work they need to.

I will look into your suggestion above some more but is this also not another work around with similar results? Additionally, when moving/ creating new views for surveys before (on top of the default ones provided when publishing) this has also caused issues (at times complete remakes of surveys needed) due to the way the settings are handled within Survey123 (where control over what viewers/ submitters can do). This would also mean more content to manage and host in AGOL. 

With this in mind, I believe esri need to consider allowing Viewer licenses further capability within Survey123 so there is a "middle ground" for this type of user (e.g. allowing them to edit their submissions) while sharing is kept to an organisational level and not exposed to the pubic.

Please do clarify anything further I have missed from your response.

Thanks.