Survey 123 Dynamic Questions and Related Table

[CallumSmith2]

Hi does anyone know if this is possible in Survey 123?

Say I have a survey with a "select_one" question that presents the user with a number of options. Depending on what option the user selects they will be presented with a number of Y/N questions. These questions will be different depending on the option and the number of questions can vary as well but they are always Y/N answers. In my scenario there are hundreds of Y/N questions but they will all not be necessarily be answered (depending on the select_one option)

i.e.

• select_one Option 1
  • Question 1 Y/N
  • Question 2 Y/N
• select_one Option 2
  • Question 1 Y/N
  • Question 2 Y/N
  • Question 3 Y/N
  • Question 4 Y/N
• select_one Option 3
  • Question 1 Y/N
  • Question 2 Y/N
  • Question 3 Y/N

I know that the display of the questions can be achieved using the "relevant" column and I understand the notion of "repeats" but I want to write the question text and the answer to a related table rather than configuring a flat feature class with hundreds of columns for all the different questions as this leads to a lot of redundancy and blows out the limitations of the feature class.

Hope this explanation is clear?

Any ideas anyone?

Cheers

Callum

[CallumSmith2]

Thanks James

I was thinking the question part might be able to be handled with hidden fields and default values but I was struggling as to how to incorporate the related table when not really using repeats.

Perhaps food for thought for your development team as we would find functionality like this quite useful especially for surveys that have lots of Y/N type questions (by lots I mean hundreds) which makes the table large in terms of the number of columns. We prefer to use feature services and the submission_url for our surveys and we are finding that we often go over the 500 column limit for enterprise geodatabases.

Regards

Callum

[Anonymous User]

This might...no it will sound absurd, but could you do some post-processing of the data? Just thinking way outside of the box here, but could you essentially modify the Survey to contain a bunch of hidden related tables. Plus create a tool that would allow you to point it at a FGDB of your dataset and process the related tables to end up with your one large table? I think that you would need to figure out some sort of Survey ID also; as this would allow you to query out the responses per survey submitted; since you have questions that can be skipped.

I am unsure if there is a limit on the number of related tables, but if you made a related table that contained data fields named "Survey ID", "Question Asked", and "Answer Given". The "Survey ID" field would be some sort of Id that you generate at the beginning of the survey, "Question Asked" field would contain a default value that matched the question being asked, and then the "Answer Given" field would contain the answer to the question being asked.

Now you would have to increment the name of each related table's question and answer field in order to have unique field names; i.e. Question2, Answer2, Question3, Answer3...all the way to your last QuestionX, AnswerX.

Next you would have to create a master template table named Final_Question_Answers_Table that contains a schema of three text fields; "Master_Survey ID", "Master_Question Asked", and "Master_Answer Given" that would data entered into the related table data fields.

Next you could build a Model builder or python script that will take your Master Template Table and merge all of the related table records into that table; via field mapping portion of the tool, to create the table you are looking for. You would have to point each of the data fields into the corresponding Master data fields' please see screen shot below.

Essentially, the survey is filled out and submitted, then you would have to download the data, after downloading the data, you could point the tool to the FGDB, allow it to process your data, and end up with the table that you want.

Like I said this is a far out in right field idea that would possibly get you what you need in the long run.

There might be an easier way to do this, but I'm shooting from the hip after understanding that you want a very lean table.

Maybe this will spark a better idea of how to handle this?

Good Luck!

Mike

[CallumSmith2]

Thanks Mike

Yes that is essentially where I am heading. We are not going to use related tables we are just going to have a flat feature class with lots of fields for all of the questions and then we will post process it into a related table so that there is 1 record for all of the Y/N questions (i.e. Normalise the structure). Our survey is configured with a submission_url so the survey data is stored directly in our enterprise gdb so no need to download. The python script can be scheduled on a regular basis to run against the enterprise gdb.

Thanks for your help and ideas. Much appreciated.

Regards

Callum