Survey123 Repeated Record without publishing

[KPyne]

Hello,

I currently have a published survey that contains a repeat and a nested repeat. The form is submitting to a submission url/feature layer that contains a single related table.

The nested repeat questions are summarized into a separate field, so I do not need a second relationship table for the nested repeat. All esri:fieldType values within the nested repeat are set to null. The formatting of repeated questions is preferred over other methods to summarize values so I would like to keep it (in the S123 form only).

Whenever I attempt to publish the survey, it states it cannot find the nested repeat table, despite all fields being set to null. 

Is there anyway for Survey123 to ignore the nested repeated table, and just let me use the repeat feature in the S123 mobile app?

[ChristopherCounsell]

I do not believe the Esri bind field type applies to repeats. The document identifies it as pertaining to questions, and lists question types it supports, but doesn't identify repeats - likely as they are not fields or questions

https://doc.arcgis.com/en/survey123/desktop/create-surveys/esricustomcolumns.htm

This may be separate, but also worth noting you could encounter issues with a repeat if no questions are between it. I don't think it applies as you have questions, but could if the issue was field based

https://doc.arcgis.com/en/survey123/desktop/create-surveys/xlsformrepeats.htm

I don't think there is a way to have a repeat but no table created for the repeat to exist. 

You could approach the survey design differently, possibly using relevancy questions, or just creating the repeat table? 

[KPyne]

Thank you for your response.

I believe you are correct in that null values in the FieldType column do not apply to repeats. That is a small shame, as I really like the UI of repeats, especially for quickly populating an unknown number of items. I am using a workaround for now, but it is a bit ugly.

How would I re-create the repeat table?

My purpose was for the user to input the type, size and length of scrap pipe. There could be no scrap pipe, or there could be 5+ different segments depending on a job. I had a repeat setup to quickly add additional segments, but then a single field (outside of the repeat table) was populated that concatenated all values in the repeat (EX: 25' of 6" HDPE pipe, 150' 4"  PE Pipe, etc).

This way it can be easily added to reports and other workflows without dealing with a large related table. I was trying to avoid hiding/showing "scrap_size1, scrap_size2, scrap_size3, etc"

[ChristopherCounsell · Accepted solution]

Before repeats existed, we could create a mock UI by repeating the questions several times in the form and then adding relevancy through a "how many records do you have" or "would you like to capture another record" question. It was a bit limited, as it required the fields to be added to the parent table. Repeats and related tables are way better. It could work in your scenario if the users have a limited number of related records - especially as you are not seeking to actually store the records being entered.

If you want functionality in Survey123 I would strongly encourage you to create an ArcGIS Idea. Lots of community submitted ideas make it through, especially for Survey123 and ArcGIS Pro. Users can vote for the idea as well.

The best ideas are detailed and have workflow context. In this case here you would really need to expand upon why the related table needs to not be created. It's not something I personally see a need for and the product team might have a similar view. It'll help them assess the benefit to effort ratio.

https://community.esri.com/t5/arcgis-survey123-ideas/idb-p/arcgis-survey123-ideas

Ideas garner community support. Formal enhancement requests can be submitted through technical support and also linked to an existing Idea. I find enhancement requests are good when there is a high business value for large or many accounts, but ideas are better when it's something that garners community interest. It will still come down to desire/value vs effort to implement.

[KPyne]

Ah okay, that is currently how I am working around it. I have 5 fields for each question I need repeated that are hidden based on relevancy. It is working fine for my case especially since I do not need to publish those 15+ additional fields. 

I will go ahead and submit a request. Although it does not improve functionality, I think it would be a nice UI enhancement and potentially minimize the amount of fields required to complete a task.

Thank you for your help!