Hi, writing in to report a pernicious problem that is cropping up in certain situations.
The general pattern is that an existing record in a Hosted Feature Layer with properly populated fields is being retrieved somehow into S123 (via Inbox or via URL scheme in a Dashboard) and, under certain ideosyncratic conditions, some populated values show up in the retrieved record as blank. If the record is re-submitted, these blank values will overwrite the existing correct values in the data layer.
One example are text fields with input masks retrieved in the web browser version of S123. They are being linked to from a Dashboard. The input masked fields come in blank, but when the mask is removed they come in properly (this is the workaround in our case).
Both of these examples occur in QA/QC workflows where reviewers are retrieving records submitted by other users on other devices. So we just want to bring it to your attention, since the end result if unaddressed is that a normal review will actually corrupt existing data.
It sounds as if the input masks, calculations or relevant statements being used could be conflicting and when the survey is opened in edit mode, they null out the value. This can happen for a few reasons but it depends on the configuration of the questions in the form. Are you using "null" question types for any of the calculations or not storing values that woudl be needed to update the form in edit mode?
It seems you are using repeats, but do you use repeat_count also? There are some known issues and limitations with repeat_count, and other issues with editing repeats via Inbox or web app and URL parameters.
Can you please provide a copy of the XLSForm (xslx file and any files in media folder)? Also exactly which questions are having the issues, and any workflows or steps to reproduce the problem?
Was this survey created in Connect or web designer? Has it since been republished with latest 3.13 release, and is version locking enabled in the settings for this survey, do you open it with latest version always?
And lastly, have you raised a support incident with Esri Support, if so what is the case id or BUG number?