Survey123 from feature service: Default value not working

[AllenDailey1]

My organization is currently configuring a survey, using Survey123 Connect, that is based on a feature service hosted in our Enterprise database.  We have been cleaning up the Excel form that was generated when we used the feature service to create the survey (fyi, we already created a version of the survey that worked perfectly, using ArcGIS Online rather than a feature service, so we know the survey settings should work. Now we just have to get it to work with our Enterprise database).  

Just about everything is working great, except the problem is that default answers (question type select_one) within a repeat are not working.  Why is this?  

We manually entered default values in the feature service within ArcCatalog and also checked that the defaults were entered correctly on the Excel spreadsheet.  Default values for the same type of question (select_one) are working fine in other parts of the survey, parts that are not in a repeat.  We also checked that the "name" in column B was correct.

Turns out that the default values within the repeat work when the name of the repeat is changed back to its more plain name, without the database prefix that was automatically added when the feature service generated the survey.  But if the database prefix is taken away, the data does not go into the table in the database.

Any ideas??

Thanks!

[JamesTedrick]

Hi Allen,

Can you update the service by renaming the repeat table name in ArcMap/ArcGIS Pro & republishing so that it isn't a DBMS table name (i.e., with periods)?

[AllenDailey1]

Thanks for your reply, James.

We have not dealt with changing the table name at this point.

But, upon further testing, we discovered that the default answer was indeed working, within the repeat, but only for instances of the repeat other than the first instance, i.e. the default did not show up in the first instance of the repeat, which was already open when the user began a survey.  So we think that if we set the repeat's appearance to minimal, so that the repeat is not open when the user begins a survey, the default will probably work for all instances of the repeat.  Weird!  Do you know the reason for this behavior?

Thank you!

Allen

[DougBrowning]

Bump since this is happening to me also.  The default value does not work for the first record in a repeat.  Does work on repeat 2 and on.

Any news on this one?  Still in 3.9

thanks

[AllenDailey1]

Hi Doug,

The trick I mentioned in my previous post, making the repeat's appearance "minimal," did work!  But of course it would be ideal if it would work without having to change the appearance.

Allen

[GregHacker1]

I'm having a similar issue where I have a nested repeat and the default values aren't being populated for any repeats, 1st, 2nd, or otherwise.  I tried to minimal appearance trick and that didn't work.  I've done some investigation and it looks as though the query in the bind:esri:parameters column is overriding the default values. 

I have some older data that aren't tagged with the value that I use as the bind query for the nested repeat. The parent repeats pull up in the inbox and the field app seems to assume each parent repeat will have a nested repeat and those nested repeats (without pulling data from the feature service) use the defaults I've set in Connect. 

The newer data that have the query tag for the nested repeat will not use defaults whatsoever.  The inbox is pulling some data from the feature service, but most data for the nested repeat needs to be updated still and most of that data is the same for each record.  So, defaults would work great here, but it seems that the inbox is pulling the empty data from those fields from the feature service rather than populating the defaults.

I've found a not so great way around this issue by using calculations, but it isn't ideal as folks still have to click the refresh icon to get the data to calculate in the inbox.