Shape Behaving As a Button


I’m a bit new and trying to figure out Bubble. I have a single page app that is a ~20 question survey. I have created “Survey Data” as a thing at the start of the questionnaire and as the user enters information I have a state that advances and changes which question is visible at the time. Each question is in it’s own group.

Many of my questions are not simple text inputs, but are instead stylized shapes with text inside of them. An example question would ask the user to choose a box and when that box is clicked I would like to record to a field in Survey Data text data on which box was selected (e.g. “Box 3”). In Workflow I am able to identify the field to write in Survey Data, but I cannot force a specific text string to be written.

In the example below, the user can select one of three boxes. I would like to save Survey Data field Experience = “Informed” in this instance.

Am I doing this fundamentally wrong? Should I be using a repeating group for these entries or some other kind of list?



Hi there, @chrismoris… there is nothing wrong with the way you are approaching this scenario, and you should be able to save the data like this…


That being said, it can be a bit tricky to get the text in there because you have to click in the dark area but outside of the little box that says Click


Then, if you actually want to get rid of the little Click box, you have to backspace over it and then click in the dark area again. At that point, you will be able to type the text you want to save to the field.

Does that make sense? Hope it helps.


I feel like an idiot. This is the most obvious solution ever. It was the UI that was hanging me up.

I think specifically, the behavior is different than if it is a simple integer. Probably something to fix!


1 Like

The issue I am having now is the data is not making it to the DB after the first question:

Step 1 - Input field creates a new thing “Survey Data” with First_name as first input
Step 3 - User selects box and we make a change to “Survey Data” with Experience = informed

The database shows the original entry with first name, but not the update with experience.

I think this may be due to the data types and nesting of groups. This is how I have it set up:

  • each Step is in it’s own group with “Type of Content” blank
  • the survey page (of which all groups are on) is Type of Content = Survey Data
  • I have also tried this with Type of Content = Survey Data for every group with the same results

Am I not passing data back in a correct way?

First Step

Make a Change

Missing Data

Data Routing Options


I’d have to poke around under the hood, and I could be way off base here… but I think the issue could be that the current page has no knowledge of the survey that is created in the first step. So, after the Create a new Survey Data step, you might need a step that sends the data from that step to the survey page so the page knows which survey to update when subsequent steps are completed.

Again, I could be way off base, so just food for thought and/or something to try.


@mikeloc I definitely need that step. At the Create a Thing step it doesn’t associate that thing to any specific owner (page, group, whatever). Later when Making a Change to a thing it does need to know the association of the thing.

How do I add the step to define the Survey Data is part of the Current Page?



Again, without knowing exactly how you have everything set up and without playing around with it myself, you could try the Element Actions >> Display data workflow option, with the Element being the survey page and the Data to display being the result of step 1 of the workflow.


@mikeloc Here is a copy of the code. I tried to do what you mentioned with no success unfortunately. Thanks a ton for taking a peak!

Okay, I added an action to the workflow and it’s saving that change to the db now.

Are you going to have users who have signed up before they can complete the survey? I assume the answer is yes, and if that is the case, you are going to want to think from that perspective and reference the current user’s survey as you go.


@mikeloc That’s awesome. Makes sense. It seems like I could keep passing the data at the completion of each step/workflow to the next and it would carry over.

Couple things:

  • I’m realizing that if I go this route with each option as a separate group / rectangle that I would need to create a new workflow for every option the user selects. Is there a better way to do this? Otherwise I will have 10 questions with 4-5 answers each (50 workflows)…
    I guess the alternative is to create a repeating group and store the HEADING text and BODY text in a data base for this object? Even then it seems like you’d end up with quite a few things in the database (every time you have a repeat multi-choice question)?

  • On the signing in… my hope is at the end of the survey the user can add a password and email and at that time I would tag the survey results with the User-ID or otherwise join it based on email at account creation. Interested in your thoughts.




Is there a better way to do what you are doing? Depends on the definition of better. Are there simply different ways to do what you are doing? Well, of course. For example, those shapes could be options in a dropdown; the user selects an option, clicks a button, and you save the selected option to the field in the database. Now you have one workflow… great! Or is it? If the dropdown isn’t the experience you want for your users, then what have you gained?

Here is my two cents (and I am ready, willing, and able to accept someone who has a lot more knowledge than I do coming along and telling me I have it all wrong, especially when it comes to how to build things in Bubble)… create the user experience you want and use the tools in Bubble to facilitate that experience as opposed to constraining the experience based on the right way to do it in Bubble.

Are there some exceptions to that line of thinking? Sure. Don’t create a database structure that flies in the face of conventional wisdom on the best way to set up a database. But when it comes to workflows in Bubble, my thought process has been to get something working from end to end, and then look for ways to optimize it if the user experience is suffering because I didn’t do it the right way the first time.

All of this reminds me of something that I and one of the most talented developers with whom I have ever had the pleasure of working used to say… make it work, make it easy, make it magic. You can sit around for weeks looking for the best way to do something or you can get something working and then make it easy/magic (however you define those things) from there.

Anyway, sorry that turned all philosophical and stuff, but hopefully it’s reasonably good food for thought. At the very least, you’ll certainly think twice before asking for my thoughts again, eh? :slight_smile:


@mikeloc Thanks for the feedback.

I’m thinking to try this:

  • Create a question database where the step, text, sub-text, and value are stored for every answer
  • Conditionally render the prompts off of a search for in that data base
  • Maybe have 2-3 different layouts based on the state (e.g. single text input, multiple box input, and radio button input)
  • Use repeating groups to render the multi-input portions

That’s my current line of thinking. Interested if this sounds good or a headache.



Before you go down the path of the question database, check out options sets (if you haven’t already) as a potential way to store your questions and their associated attributes… might be a good way to go.

About using repeating groups to render the multi-input portions, I would have to see that in action and/or play around with it myself before I could truly weigh in on it… but it could certainly be an option.


@mikeloc Great point! I went ahead and switched over to the method you mentioned and used repeating groups to render the boxes. Much more efficient!



Happy to hear it, @chrismoris! Oh, and apologies again for the philosophical tangent earlier in the thread… just didn’t like the idea of you “compromising” your design, and that sent me off on a rant. :slight_smile:


This topic was automatically closed after 70 days. New replies are no longer allowed.