Hello,
Is there a way in Survey123 to simplify cascading selects so that you don't have to write out every single possibility when creating choices lists to use in the choice_filter?
For example, I want a user to select a number (1-6), and if they select 6, they must choose one of 3 options in Question 2 ('cool colors', 'warm colors', or 'only purple') which further filters their choices in Question 3. Question 3, "Pick a Color" is dependent on both the answers given in Question 1 ("Select a number") and the answers given in Question 2. I want my choice list to look like the following (see red box in following image), where the blank cells have some sort of value or formula in them that specifies that for those cells, the value can be blank or can be anything.
However, currently that doesn't work and I have to write out every single possibility in the choice list. This option is mistake prone but also gets really complicated and hard to check for errors when you have really long lists and have say 4 fields determining the choices given in a question and not just 2 fields.
I did find one work around show in the image below, but it is less than ideal because you have to ask the user Question 2 for every answer to Question 1, not just for '6' which is the answer which denotes the need for Question 2.
Does anyone have any ideas? I've attached my example Survey123 Excel form for reference.
Thanks,
Blythe
Ismael Chivite Cesar Garrido Lecca Rivera
Solved! Go to Solution.
A team member and I discovered that when using Survey123 Connect, you can avoid some redundancy of typing out every possibility by using a combination of choice lists and relevant column logic, as well as incorporating logic for when something is not a particular value.
So for the initial example, I might have different "Pick a Color" questions show up based on the user input to the first question, and then concatenate the answers for the final answer at the end, since empty questions won't add any unnecessary characters to the answer. That creates more work for simple examples but can sometimes create less work for long choice list logic trees.
Also, we found out that you can also use a "not" function in a relevant column to cut down on writing out every possibility, but only by taking a work-around approach. (For example, creating a calculate question that populates a field as 999 if the answer is 'purple' and 0 if the answer is anything else. Then, in the relevant field, have one of the relevant expressions be string-length(${purple_check_field}) > 1).)
Hi Blythe,
This is somewhat difficult as the choice_filter in Survey123 field app and Connect are somewhat limited in expression support. If this is being intended to use for the web app, the attached file can be used - it uses an additional column in the choice_filter for each choice.
Hi James Tedrick,
Thank you for the reply, that would be a really great way to format it. Unfortunately, I do need to use this survey in the Survey123 field app and in Connect.
What would you suggest would be the best way to go if making the survey for Connect and the field app? Writing out all possible combinations?
Also, am I safe to assume that if something works in Connect that it will work in the field app?
Thanks,
Blythe
James Tedrick I'm using this method in S123 Connect and the field app, and it's working. Is there a limitation to this method for the apps (vs web forms)?
Has this issue been resolved? Is there any other work around's besides the options here because it is still a pain.
A team member and I discovered that when using Survey123 Connect, you can avoid some redundancy of typing out every possibility by using a combination of choice lists and relevant column logic, as well as incorporating logic for when something is not a particular value.
So for the initial example, I might have different "Pick a Color" questions show up based on the user input to the first question, and then concatenate the answers for the final answer at the end, since empty questions won't add any unnecessary characters to the answer. That creates more work for simple examples but can sometimes create less work for long choice list logic trees.
Also, we found out that you can also use a "not" function in a relevant column to cut down on writing out every possibility, but only by taking a work-around approach. (For example, creating a calculate question that populates a field as 999 if the answer is 'purple' and 0 if the answer is anything else. Then, in the relevant field, have one of the relevant expressions be string-length(${purple_check_field}) > 1).)