Forum Academy Marketplace Showcase Pricing Features

How to Require Answers to Questions on Survey Form Submission when using custom states for selected answers

I have a survey where I ask user’s to rate, on a 1-5 scale, a list of people. The list length is dependent upon the number of people attending an event.

I’m storing the 1-5 scale answers as custom states. And, not using a repeating group for various reasons.

What’s a good way to validate that a user has answered each visible question on form submission, given that the # of questions is variable in length?

Also, is there a way to submit only the questions that are visible (so I’m not creating empty rows in the database) without having to create a separate workflow for each possible # of questions on the page. Note - I ran into trouble having the answer auto-submit when selected since it only worked 95% of the time (and I need this data to be 100% correct).


Can you share a link to your app? That will give a better idea of how to do this with your data structure. :slight_smile: I think one way to ensure that a User has answered the total amount of questions within a form is to create a custom state called “Questions Answered” (Type: Number, List: No), and then only allow the User to continue when Questions Answered is equal to the value of “SurveyQuestions:count”.

Thanks @fayewatson!

Here’s a screenshot of this page.

The labels of Role 1, Role 2, …, Role 5 are text customized by an event organizer (i.e., a customer of ours). They can include between 2 and 15 roles. The ratings of 1-5 for each are done with a reusable element. Each has a custom state attached that saves the value. I’ve also been saving this data to our database when a user submits a rating (or updating the rating if it already exists in the database), but we’re run into problems with this and only seem to get the correct data 95% of the time. We’re using this data to match end users for video calls, and it breaks our matching algorithm if we send it too many or too few rows, so looking to re-work this to store everything on submit so that we can be 100% sure it’s stored correctly.

Sounds like your solution may work. Open to any other ideas you may have as well. Thanks again!

Very cool setup :slight_smile: I’m not entirely sure how to do this yet; I’m trying to replicate what you did in the forumapp. Are your Role text and Star Rating reusable elements within a repeating group? If so, how are you calculating the total sum of each cell’s custom state star rating value right now?

The question label is text that’s dynamically pulled from our database.

The star rating is a reusable element. In the reusable element, we change the custom state of the group whenever a user clicks a star rating.

We set-up each label/star rating as a group. Did not set as repeating group (since we’ve run into other constraints with storing data from repeating groups in the past). So, we have 15 different groups of labels/star ratings. Each group is only shown if there is a label for it in our database, since sometimes there’s only 2 roles to rate and other times up to 15.

Currently, we have workflows that store the user’s star rating anytime a user selects a new value. In theory, this would mean we don’t need to submit anything when they submit the form since everything has been submitted already. But, we’re running into a bug where some of the data doesn’t get stored every time. Submitted it as a bug earlier today so hopefully Emmanuel can help us figure that out, which would minimize the need for rework.

Still need to run a check to see if user’s have answered all of the questions. I like the concept of your suggested solution. Seems simple / elegant.

One question - would it work to just have the custom state for “# of questions answered” increment +1 anytime the stored value for our questions do not equal null? (so it only counts it 1x per question even if a user selects a different answer)? Is that how you’ve done this before, or did you have something different in mind to address that edge case?

Thanks again – all very helpful.

Hey Scott :slight_smile: Sorry for getting back so late on this - I created a demo in the forum app, but I did end up using a repeating group. The data structure/setup is different from what you explained, but I think you could still keep what you have and still use the method below.

In order to make sure the count of questions a User has answered was accurate - I did this by creating a custom state on the page that was a List of Roles. Anytime a star is clicked (whether it’s in a cell, or a group in your case), that Parent Group’s Role or Current Cell’s Role is added to the page’s List of Roles.

Then the continue button doesn’t become clickable until the page’s List of Roles:count is equal to the total number of Roles listed. Here I just used the repeating group’s count for total number of Roles, but in your case it would be the number you use to determine how many reusable elements to display to the User (I think) :slight_smile:



1 Like

Thanks @fayewatson. Appreciate all of the help.

I’m curious, have you done any UX testing to evaluate whether users understand the continue button not being clickable means they need to finish answering questions? …I know this is Bubble’s default set-up for surveys and forms, but it doesn’t seem obvious to me that user’s would understand this since it’s not a common UX practice on the web. But, perhaps my intuition is wrong. I’m curious whether anyone has tested this? …@emmanuel, do you have any experience / insights on this?

As an alternative, I could use the same logic for calculating how many roles have been answered and then just show an alert if they click continue before having answered all of the questions.

No problem at all. :slight_smile: And same here, I prefer to set this up in the workflow on the button so that it’s: “when button is clicked” and when: [the User hasn’t answered all of the required questions logic] --> show an alert. I don’t really use the ‘not clickable’ option - only for this example really to show that the page was keeping the correct count of how many questions a User had answered.