I have a survey I am building that will have to be shared publicly so those with view licenses are able to submit, however is there a way to force the survey to have them sign in before opening the survey?
EDIT: For clarity, this answer is related to a problem which is separate from working with named Survey123 users (i.e., users with Survey123 accounts). Please see @MobiusSnake's answer if you are working with named users in Survey123.
Yep. This clears things up. Essentially just ensuring submitters are "authorized submitters". I am in a similar boat.
There are several ways to go about this, but it can depend on your IT structure (e.g., do you use Single Sign On, aka SSO) and business set-up (e.g., are you in the "public sector") as to what will work best.
In my case, I am Public Sector with SSO accounts and my company is heavily into Microsoft's environment. As such, I have found great success with these options:
There are a few more ways to look at this. For example, I am in the process of building a new PowerApp that uses SSO and ArcGIS connectors to link our two environments. It's a pretty neat thing that I just started, but I am hopeful it will help with the particular security issue. You don't need to go this fancy though.
Maybe not before opening, but before submitting...
I haven't tried this, but maybe you could have a hidden text field named something like "current_user", with a calculation like this:
pulldata("@property", "username")
That will grab the currently signed-in user, if they're not signed in I'm pretty sure it'll return an empty value. If it's required that should prevent them from submitting. You could add a validation message or a second related note question that tells them they aren't signed in, and they should close the form, sign-in, and re-open.
That will grab the currently signed-in user, if they're not signed in I'm pretty sure it'll return an empty value.
It will indeed return <null> if they are not signed in. If going with @MobiusSnake's solution, I would suggest using string-length() to determine if the field contains data or now. Would be the most reliable. E.g., string-length(pulldata("@property", "username"))>0
This set-up seems very counter intuitive though. Why would you want to set this up for public data collection, but then further require users log in? Not sure I see the benefit here. Seems like it would be easier to set this up for accounts only.
circumvents the licencing requirement while allowing checks of username submission
People with viewer type licenses can't submit the survey unless it is public that why. If I could lock it to our teams account and not have it public then I would, but then most of the team would not be able to submit the survey.
There's already a username field type that automatically gets the login name, at least in S123 Connect.
Signed in members can post, follow updates, and more. New here? Register a free account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
