I would like to see an enhancement that would allow writing to the same related table from different parts of an inspection form. For example, we are performing an inventory on a system. We would like to be able to walk users through a list of different subsystem inspections by having a repeat header for each subsystem. Users need the ability to add multiple records for each subsystem. However, each subsystem inspection is currently being written to its own table, resulting in a very messy database with dozens of tables. I considered adding a dropdown for subsystem within the repeat, but it is easy for an inspector to miss a subsystem type this way.
I tried using the same name for the repeat to try to force it to write to the same table, but got an error in Survey123 Connect about multiple elements having the same name.
Not sure I get it but it might be similar to what I had to do.
I have a set of Transects A to G to go though.
So I create a repeat set the repeat_count to 7 so I know the exact amount.
Then I use the once(count()) trick to figure out which repeat I am on.
Then I have a calc field that does a lookup to a csv.
That csv has a simple lookup of 1=A, 2=B, etc.
In addition to Doug's comments, I would mention that it is possible to hide or show groups of questions within the same repeat - you could have one repeat with information on all the subsystems and then hide or show individual subsystems based on the other questions in the form.
Thank you for the responses! I think the issue is that we have a non-linear data entry process. Users are walking through a building and inventorying structures they find within buildings. They will create a separate record for each unique type of a subsystem that they find. This means that they have to tab through pages in the repeat to find records for each type. What we expect to find in each building is highly variable so it is not practical to use a set repeat count to try to pre-fill fields.
Doug, I had thought about a solution similar to what you suggested which involved filling out the subsystem as a separate question and then using choice filters and relevant filters so that the form would display the appropriate choices and questions based on the subsystem that was entered. However, given the number of possible combinations of types and subsystems, it is impractical for the inspectors to tab through that many records to find the appropriate subsystem and type if they encounter that particular structure again later in the inspection (it could be over 50 different combinations per system). An alternate solution that would be helpful would be a different way to display repeats using the grid layout. If the repeat records could be viewable like a table rather than records to tab through, that would be incredibly helpful for this scenario. This way, users could easily view data they had entered and would not have to go back and forth through the records or try to remember which types they had already entered.
I also considered having them write down every instance of the types separately so that they would not have to tab through the repeats and then trying to apply some logic outside of the repeat to summarize the data as it is entered, but it there is some user interpretation that is applied during the inspection that is difficult to capture programmatically through the form.
We would like the resulting data to be formatted as:
System Subsystem Type Rating Quantity
Subsytem1 Type1 Rating Subsystem1 Type1 Quantity Subsystem1 Type2 Rating Subsystem1 Type2 Quantity ... etc...
There is a list of ideas to upvote for growing repeats in this post https://community.esri.com/thread/261537-a-datasheet-format-for-survey-with-repeat-entries
You can also use join() to create summary pages of data.