In Survey123 Connect, I designed a survey that asks users for the number of locations that they need to collect data. Based on their response, different sets of questions are displayed. If the user select the option of less than 10 locations, a specific set of questions appears. If they select 10 or more locations, another set of questions is shown. I've used the body::esri:visible column to control this visibility. The logic works correctly when I test and update the survey123 connect app on my system but when I publish the survey to our portal the logic does not work for '10 or more' locations and it is not displaying as expected and they are shown for even if users select less than 10 locations. The questions related to the more than 10 locations are within a repeat. In the repeat there are two additional questions that should always be visible, regardless of the location count.
Thanks @TylerGraham2 , I edited the line 35 and used the selected() but still lines 39 to 42 are visible for less than 10 locations as well. I added the selected() in the relevent column but it not showing the lines 39 to 42 unless the next record in the repeat is added. Could you please have a look at my xlsx form?
Thanks for sharing the xlsform. The root cause of this issue seems to be the webform and your schema. The webform appears to only be able to pass relevant and bind::esri:visible formulas from a question in a repeat table to a different repeat table, not the questions within a different repeat table. If you take the ${number_of_locations}='less_than_ten_locations' out of your “locations” repeat visible column, but leave it on the questions in the “locations” repeat you get the same behavior as you are getting in the attachments repeat.
You also get the same behavior with the relevant column trying to make questions from one repeat show/hide questions in a different one. HOWEVER, if you change your studyinfo repeat to a group, the relevant column will pass conditions to questions in the repeat tables using the webform interface.
It looks like where the Survey123 App can handle passing the visibility/relevance between questions in different tables, the webform cannot do this.
There’s a couple of ways to solve the problem and this is where you need to think about your schema. You can split out the questions required by one response into their own repeat and put a formula in the visible or relevant column for the repeat and get it to work. However, that is going to create more tables. Each repeat creates a related table in the feature service, and you have 4 already. The only data from the form going to the parent table is the additional_comments field. Managing related tables is a chore because as soon as your global and rel_global IDs don’t match your stuff won’t work.
I think you need to look at using some groups instead of repeats where possible. Repeats create related tables where groups serve to divide up questions in the form to manageable blocks. If your question only needs to be answered once on a form it shouldn’t be in a repeat. An example would be the name or email of the person filling out the form. Looking at you form, my interpretation is the data in the “studyinfo” repeat is only answered once for an instance of the form and should be a group. Then if there are less then 10 locations, the “locations” repeat would be filled out up to 10 times, so that should remain as a repeat (you should also put a limit on the number of repeats allowed so it will stop them at 10). And finally on to the “attachments” repeat. You’re using the multiline appearance for photos and files, which allow multiple pictures/files to be attached to one question without using a repeat table and the only other question is the link to the Google sheet, which seems to be a one time per form response as well. If that is true, then you should look at making it a group instead to simplify your life later on.
Thank you @TylerGraham2 for your detailed response and guidance. This survey is part of my work for automation of our main work in our team through FME and the reason that I put them in the repeat is that I need those separate tables in the FME.
Ok, since you need the repeats, what I would try is adding a new group before the studyinfo repeat and duplicating the questions in the studyinfo repeat. Use those fields for your relevance/visibility formulas instead of the fields in the studyinfo repeat. Then set the studyinfo repeat appearance to be hidden but use the calculation column to pass the values from the group to the questions in the studyinfo repeat table. That way you are collecting the data in the group where you will get the proper function for relevance/visibility in the webform and you are still creating a separate table for that data in the FME.
If you try that, you should also consider using the null option in bind::esri:fieldType in the new group questions so those fields aren't created in the feature service and the data is only captured in the repeat table.
I didn't get the solution. I should add two groups in the studyinfo? Could you please explain in more detail? If you have time could you please apply your solution to my xlxs form?
Here's an xlsx of what I was talking about. Since you were talking about the repeat serving to compartmentalize data rather than needing to collect multiple instances of the same questions, I set it up like this. The esriFieldType for questions in the study info group are all set to null, so it doesn't create those fields in the feature service, the questions in the study info repeat are all read only and have a calculation to pull from the corresponding question from the group.
It is not a suitable solution if you are using a repeat as a repeat is typically intended since it copies the same responses from the group to each repeat and changes to data in the group appear to update all repeats when calculationMode=Always.
I added a grid layout so the studyinfo group and studyinfo repeat are side by side so you can easily see the interaction. I had to manually set up other fields for the questions that had and or_other option to be able to pass the data. There's also a bug in the webform if you create your own other field use a choice value of "other" or "Other" in the choice list. It causes a display error where the other field and the other question overlap. Changing the choice value to "other1" fixed that. I published this and tested it in the webform and it worked for me to pass the values around and get the relevant column formulas to work.
Thanks @DougBrowning, I'll give it a try