Hello. I'm using Survey123 Connect to build a survey where i ask users to select their top 3 preferences from a group of items. Each 'preference' question is a separate question, i.e. 'Choose your top preference', then 'Choose your second preference', etc. The 'group of items' is populated using the `autocomplete search()` functionality to return data from an AGOL hosted table.
My goal is to prevent a user from selecting the same item in subsequent preference selections by removing the previously selected value(s) from the 'group of items'. For example, i don't want a user selecting, say Ice Cream as their favorite food in the 3 questions asking for their top 3 food types (although that would be my preferred selections!). So, if they chose Ice Cream in the first question, Ice Cream would not appear in the 'group of items' for the second and third questions.
Esri docs say that for a nonspatial table, i can use 'contains' or 'matches' as search types. But, Is there a way to say 'does not match' or 'does not contain'. I tried putting a '!' in front of 'matches' but that didn't work
And for the filter option its not clear how the filterText parameter should be formatted for a 'negative' filter. I have the same goal: to filter records so that rows where filterColumn does not equal a particular filterText value. Any suggestions?
Solved! Go to Solution.
I am not aware of another way to do this. I do believe there is an active enhancement request though for this particular feature.
My suggestion would be to use constraints and just stop them from selecting the same thing more than once. It would only warn them when they try to send (or add another repeat record if this is nested in a repeat).
You can add a constraint similar to...
${option_a} could have a constraint of .!=${option_b} and .!=${option_c}
${option_b} could have a constraint of .!=${option_a} and .!=${option_c}
${option_c} could have a constraint of .!=${option_a} and .!=${option_b}
At the Dev Summit this week, all the Survey123 folks were super helpful. For this particular issue Zachary Sutherby ( @ZacharySutherby ) suggested the following which is working exactly as i needed (sorry for the screen shot but that's what i got for now).....
You could always have 1 calculate per option to determine if it were selected or not. Then concatenate all those calculates and use that list in the WHERE clause.
That way, if someone selects "apples", it will be removed from the list:
Hello @abureaux . Thank you for sharing your ideas.
If i understand your suggestion correctly, in my case it doesn't seem feasible to do a calculate per option. My list of options are coming from an AGOL standalone table via the 'autocomplete search()' function, the options are dynamic with not infrequent changes to the underlying list of options, and there are upwards of 50 or so options. To me the suggested approach doesn't seem practical for the use case.
Have you seen any additional documentation from Esri (or from other users) that gives details on how to construct a more complex 'where' clause when doing an 'autocomplete search()'?
I am not aware of another way to do this. I do believe there is an active enhancement request though for this particular feature.
My suggestion would be to use constraints and just stop them from selecting the same thing more than once. It would only warn them when they try to send (or add another repeat record if this is nested in a repeat).
You can add a constraint similar to...
${option_a} could have a constraint of .!=${option_b} and .!=${option_c}
${option_b} could have a constraint of .!=${option_a} and .!=${option_c}
${option_c} could have a constraint of .!=${option_a} and .!=${option_b}
At the Dev Summit this week, all the Survey123 folks were super helpful. For this particular issue Zachary Sutherby ( @ZacharySutherby ) suggested the following which is working exactly as i needed (sorry for the screen shot but that's what i got for now).....
Ahhh. Very good.
Super sad I wasn't able to attend that 😞
Hey @abureaux .
Thank you for your suggestion. That's a clever workaround that i think will get mostly what i was after.