nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Data entered in form not coming over after submission unless focus is shifted off of field.

AndreaPecharich

We use multiple survey forms that work with repeats. Users are either selecting from choice lists, or entering numbers into decimal or integer fields for a fish, then moving to the next repeat for the next fish. Currently, if the last field in the repeat is an entry field (decimal, integer, text) and the user advances to the next record in the repeat without shifting focus way from the data entry field (tab, enter, clicking another field) no values are recorded when the data is submitted, even when they typed a value in the field in the form. To make it extra confusing when I have a calculation on that value to show a formatted sample number, for example, the calculated value is generated, but the data is not committed when the form gets submitted. This makes it difficult for the user to know they have an error. It would be helpful if data was committed to the record when the user advances to the next repeat on the form, even if they have not shifted focus off of that field. Or maybe an option to force a shift focus when the repeat is advanced?

see post on S123 Questions: https://community.esri.com/t5/arcgis-survey123-questions/data-entered-in-form-not-coming-over-after/m-p/1284468#M48978

Find more posts tagged with

Field App

Connect

Status: Open

Comments

BrandonA_CDPH

I second this idea. I too have fields that are entry fields, but you are required to navigate away to commit the answer. On the computer, it's not so bad since users just have to press "tab". On a phone, it can be much more complicated because with the keyboard up and the field at the top of the screen there isn't really enough real estate to tap "away" from the field and commit the answer.

@AndreaPecharich- As a workaround, I developed a form that had a "gatekeeper". After the field that was behaving the way you described, I had another integer field that wasn't actually recorded (Field Type - Null). That field had to be >0 in order to show the rest of the form. A little clunky, but it served the purpose. - side note: I actually made it into a "game" with a random number generating question and a note that congratulated you if you guessed the number right. Users were at least amused by that. 😁