Retrieve information from a feature service based on the logged in user's username

[HanliePetoors]

Hi,

I'm working in Enterprise 11.3.

I want an app or something that allows a user to add information about them in addition to what is stored inside portal. An example is a cell number.

When the user opens the application/survey it must

* display the user's full name based on their login's username.

* allow the user to capture a new record if none exists for them

* allow the user to edit their existing information if they already have a record.

Each user may have only one record.

I have tried using survey123 but I can't get it to not submit duplicate records.

I have spent days on this without any success.

Does anyone have any ideas? It's not within my capabilities to build a custom widget.

Thanks

Hanlie

[LReis]

Since you're submitting this in the Experience Builder forum, I'm going to assume you're considering using Experience Builder and perhaps embedding Survey123 within it. Have you tried using a Survey widget and enabling the option "Edit an Existing Record"? It sounds like that might provide the functionality you're looking for, and I've used it successfully such that it did not create new records in a feature layer.

[HanliePetoors]

Thanks for the suggestion.

I did consider having a web experience with a table in which the user can select their username and then that can populate an editable survey form. It would be ideal to pick up the username automatically and select the record by default since people will only ever see their own record in that table.

Also, somewhere the user must be able to create their record at first and I can't find a way of preventing them from using this form twice and creating duplicate records for their username. 

I found a post by someone who managed to disable the submit button based on whether a record exists or not (https://community.esri.com/t5/arcgis-survey123-questions/disable-the-submit-button-on-survey123-form...) but I couldn't get it to work in my context, even after I worked with a colleague with lots of experience in Survey123. If I could get this working I wanted to display a link to the survey form with mode=edit if a record did exist.

At the moment the best I can come up with is to retrieve the user's information if it exists and then use a database trigger to clean up the duplicate record since the service is based on a table in an enterprise geodatabase. Not very elegant and not usable for hosted feature services but much simpler to maintain. I find Survey123 to be very finicky.

Regards

Hanlie

[LReis]

I realize you’ve figured out a solution for this already, but given that I couldn’t find an easy resource for this question I figured I would share some ways to address the problem.

1. Database constraint: One way of ensuring that users can’t create a duplicate username would be to set a uniqueness constraint at the data level (Data > Fields - an image for this is below). However, Survey123 doesn’t check against this when a user enters a value. This means that while the survey won’t submit successfully, the user won’t get a useful message (it’s something along the lines of “database error”). I also believe it wouldn’t be case-sensitive.
2. Use Survey123 Connect and pulldata(): The basic idea is to have a hidden field that looks for a duplicate value in the username field, then check to see if that hidden field returns any values as a constraint in the data entry field. I’ve attached a sample spreadsheet that implements this idea. In the pulldata lookup, I added LOWER to both sides of the WHERE clause to make sure there weren’t problems with case sensitivity. In theory, you could add additional regex checks on the username field if that is important.

Hope someone finds this helpful!

[HanliePetoors]

@LReis thanks for giving your example.

Mine works a bit differently because the user does not enter their username, it is retrieved from the logged in user's Portal information. This username is saved to the feature service so that the survey can count the number of records in the feature service that have the logged in user's username in the service. Then it must prevent the user from submitting another record if count>0. Simple in theory but thus far beyond me.

I agree that the silent fail of a unique constraint is not really an option.

Regards

Hanlie