Best way to create data types using multi-step form in Bubble?

Need help App Organization
1

Hi guys, I’m trying to create a data type “Interview” using this steps: https://i.gyazo.com/212e1ae0c1af66984c87b8c3f133d76d.png

I’m trying to create a multi-step form with each step that’ll change depending on how the previous question was answered.

So the first question will ask if they’re applying for Marketing or Developer position. And then if they choose Marketing, then it’ll ask for their location with choices US, Canada and UK. If they choose Developer, then it’ll ask for their location with choices US, India and UK… and so on.

I have “Interview” data type with fields i.e. Department, Location, Specialty, and In-house. Each field is an option set.

Is using option sets with conditional statements for each step the best way to do it? Would there be a better way to achieve this?

2

Hello @jsk9242 Welcome to the community!

Nice project!

If the choices do not need to be created by a user then OSs will work fine. The Bubble dev can add more or edit them as needed from the backend (the Bubble editor).

4

Hi @cmarchan, thank you for the reply!

So the conditional statements would be like this, right?:

If Department = Marketing, show option sets ‘US’, ‘Canada’, UK’.
If Department = Developer, show option sets ‘US’, "India’, "UK’.

If Department = Marketing and Specialty = SEO, show option sets ‘Content writer’, ‘Page optimizer’.
If Department = Marketing and Specialty = Cold Calls, show option sets ‘B2C’, ‘B2B’.

And so on.

It does get a bit complicated down the chart as I have to add more and more conditions. Would there be any other way to achieve this so it’s more organized by any chance?

5

@jsk9242

Data types :slight_smile:

6

@cmarchan So using data types instead of option sets, right? But I’m still not 100% sure how that would work. Could you explain how I would set the data types up?

7

Intelligent use of optionSet attributes can be very useful here, and would avoid having to use conditionals for every different combination of previous selections; you use a single dynamic expression to capture all the possible combinations.

Attributes can be set to lists of other options. For example in your Location optionSet you could create an attribute called ‘Department’. It would be of type Department, and it would be a list.
For each Location, you would manually set the list of Departments on which the particular location is selectable:
US = Marketing, Developer
Canada = Marketing
UK = Marketing, Developer,
India = Developer

Then in the datasource for selections you can simply use All Locations:filtered > Constraint = This Locations's development contains [Dynamic experssion for selected department]

Read the general tip at the end to see how i would populate the dynamic expression for selected department

The nested selections (SEO>Content writer/Page Optimiser & Coldcalls> B2C/BSB) can be dealt with by creating options for all these selections on the Specialty Optionset, and then creating two extra attributes on the Option set.

  1. Subselection? - A yes/no attribute for whether the option is a subselection or not.
  2. Subselections - A list of Specialites containing the sub-selections of that particular specialty (Bubble allows optionsets to reference themselves, which is quite cool),

For the first Speciality Dropdown, its datasource should be
All Specialties: filtered > Constraint 1 = This Specialty's department = Selected Department & Constraint 2 = Subselection is 'no'
Create a second speciality dropdown. It wold be visible only if first dropdown's value: subselections: first item is not empty, and it would have as datasource the first dropdown’s value: subselections.

I can see from your PNG that you don’t have a huge array of possible selections, however the above method is very scalable and organised, and works well when your possible selections increase/change.

A general tip for setting up forms:
With the new WU pricing scheme, i would recommend avoiding autobinding, as well as triggering ‘make change to thing’ on every input change. Using customStates which get updated when input fields are changed can help reduce WU consumption & increase performance. The type of these custom states would be the underlying optionset. When the form is completed, use the ‘make change to thing’ action once, and update all the relevant fields to the corresponding customStates.
This also helps deal with user backtracking (when a user returns to a previous step and changes a selection which affects following steps)

1 Like
8

Hi @nico.dicagno thank you for the reply!

I thought about doing that as well, but it still gets as complicated because I have to add multiple fields as the chart goes down. I also plan on making a much more complex multi-step form in the future.

For example, for ‘Specialty’ option set, let’s say there are different specialties for each location. Maybe I only want to hire cold call marketers from US only. Then, I would need fields for location and department. And every step the chart goes down, it would require more and more fields.

So that would be fine for this specific example but I don’t think that will work when I create more complex multi-step form. But let me know if I misunderstood.

9

Hi @cmarchan would be great to know what you meant by using data types. I’ve been trying to figure it out but I have no idea how to structure the data types for this.

10

If you are building complex selection filtering, you’ll need to input the filtering constraints somewhere, and the above method is much quicker to set up than using conditionals for every selection combination.

Having said that, it’s probably best for you to use a dataTypes instead of optionSets. OptionSets can only be updated with a deployment to live. So if you think you’ll often change conditions/combinations, it makes more sense to use the database. It is also easier to manage database entries rather than option sets, as you can create admin pages to programatically change database entries. With option sets you are stuck with the editor.

You would structure the dataTypes exactly like your optionSets. The two can behave the same way, just use ‘do a search for’ instead of ‘get optionset’. Attributes are essentially the same as fields.

11

Thank you @nico.dicagno .

@cmarchan Any update on how I need to structure data types?

12

Think through how you may achieve the functionality that you are looking for through a hierarchical parent/child approach using database objects. Or in “bubbblish” … data types :slight_smile: