Option Sets in Bubble (are you using them correctly?)

[@carlosrocha2591]

Great video!, I just want to add that now option sets do require deployment, now it is not possible to make any changes on them on Live, so the changes needs to be done in main branch and them push them to live.

[@marmanlive]

Simply brilliant, thank you so much for making this so comprehensive and informative. After searching the internet for three days (including official Bubble resources) I finally found this video that easily explains the idea behind using the option sets. Cheers!

[@coachingnocodeapps]

I'm so glad it was helpful!

[@strongemotion]

Great video, Gabby. The one example that I was hoping you would give deeper guidance on is App Plan Pricing. That's LITERALLY what I'm building right now. I have gone with a data type for the plans+prices, but I have my plan types as an option set: "Unsubscribed", "Free + Fees", "Individual Subscription", and "Group Subscription". I really wanted to hear your thoughts, but you don't go very deep. You mention the "qty of records" criteria, but I was wondering (and others may as well) about other criteria you would use for this? Some considerations are, "How often might it change?" "How often do you access it in screens? (where subscription type drives show/hide functionality)", and "If these things are dynamically or statically represented in your payment provider (Stripe for example). What are your thoughts?

[@coachingnocodeapps]

I'd organize App Plan details in option sets if I don't expect the plans to change often and I just need a place to list the choices, their amounts, and Stripe IDs. The common thread here is that if I don't plan on "messing" with the plans too much, I can take advantage of the option sets. Be mindful you'll want multiple attributes for Test and Live IDs. However, if this data has more going on, then it's just easier to manage in a data type -- for example, track plan changes or if I anticipate some users sticking around on legacy plans while others are on newer plans or I happen to have a ton of additional attributes per plan (icons, bulleted list of included features, etc.). It's also easier to update IDs and details because I don't have to deploy -- I just update the appropriate database. Anything that is user-specific should be organized in a separate data type in the database.

[@strongemotion]

@@coachingnocodeapps Thank you Gabby, that's exactly the kind of details I was hoping to hear from you. In addition to those criteria, I have also considered that I am not building a "100 % data - driven configuration"-based system. I will have many workflows and conditionals that use these plans. It is likely that any changes to the plans (besides price) will also change necessitate changes to the app. For example, going from a current plan of "Price drives number of members" (like the lesson you have in your VIP content (fantastic, by the way), to a "Price drives available features" model. This will require changes to workflows. So just adding things to a data type is not going to change the functionality of the app. For that reason, it will be a hybrid of option set and data type values. Things like coupon codes and the like CAN be data-driven, even with variable methodologies like "percent off" or "free days" or "discount $". Thanks again for the reply.

[@tamarschirman4442]

Great video Gaby, as always! I second Paul's question about the use of OS for Pricing Plans options and user subscription status. Happy to hear your thoughts on that.

[@coachingnocodeapps]

We just commented on Paul's question! I hope it helps :)

[@simon.stjohn]

Such a valuable video....Thank you Gabby. I am learning data structure is a big issue for successful Bubble dev. I am still struggling with: (1) List of countries - if I want a user to pick their country for their profile, should this be list or OS? The list won't change over time but it seems very large for an OS. (2) Tags: If I plan on tagging tourist locations with attributes (eg: waterfall, ricefield, droneworthy) and have a list of 20 (might grow to 25-30max) should that be an OS? (3) And if I go with Field rather than OS for my Tags, is that going to be one field of type text as a list or 20 different fields? For most this answer might be obvious but as a newbie I am confused.

[@emmanuelalder9052]

Hi Gabby, thanks for making this video, super helpful. Still trying to get my head around all of this, I’m a newbie to Bubble and codeless development. I’m trying to create a restaurant menu app, where customers can select menu items and place an order. Currently I have stored the menu items in the data type table instead of the option set is this ok to do? Also when I come to display the menu items to the user, would I be able to easily pull the items from the database? Thanks in advance. I’m only a week into using Bubble, I have no idea what I’m doing still. I watched your how to build your first app on Bubble video, it’s definitely helping me out a lot. Thanks for another great video.

[@Mr.itsiem]

Hello Miss Roman am amazed by all your tutorials that i have so far watched. I will be developing my apps using bubble. but i do have a question, how do we set up Bubble development environment

[@coachingnocodeapps]

I'm so glad they're helpful for you! To get started with Bubble, I'd suggest following this video: kzbin.info/www/bejne/eoqrpYVtfrSBopo&lc=UgzdQUCQN_2qsmiHF494AaABAg

[@benme2253]

Hi! I have option set of categories: music, sport, art. I also have an option called "all categories". Is it possible to somehow include all the categories into this one? So when I select all categories , both music sport, and art are selected in a repeating group?

[@ztipster]

Thanks for the video. I think better always use data types so I dont use options set in a wrong way also I dint see any advantage for using options set over data types

[@DarlantenCaten]

Performance-wise, the options set are way better since they are static and don’t require querying the database each time. For simple types like status they are the right tool.

[@ztipster]

@@DarlantenCaten any suggestion where to find remote work ? Cant find anything in all freelance sites

[@ranc6349]

So I still don't get it. I need to have the user select from the drop box a choice, then with that choice show a list of new options where the user selects from that then saves them both to their profile. Like Cars. I first select the marque, Ford, then a list of models come up, Escort, or Ranger, then when I select model and save, both Ford, Escort saves in the record. please help.

[@aaronbarrett887]

Hello! Thank you for your work I always come to you for answers! Quick question: what about options/data that produce more options? I have three levels for a database of 1. category 2. service 3. specialty. Is it better to use Data Types or Option Sets? I've tried both and in theory they work but I can't figure out the workflow for either. Example: User journey is Category (A) -> Service (A1) -> Specialty (Aa) I am absolutely stuck and any suggestions would be wonderful

[@danielstoicamusic]

I have the same question.

[@aaronbarrett887]

​@@danielstoicamusic Hey Daniel! In case you haven't come up with a solution-I ended up creating a Data Type with 4 fields: Category, Service, Specialty and Sub-Specialty. You must input the Category individually for every Service you have within it. So, for example, on a table it would look roughly like: CATEGORY --- SERVICE --- SPECIALTY Food/Drink --- Catering --- Staff, Specialty, Dessert, etc. Food/Drink --- Bar Service --- Cash Bar, Open Bar, Beer & Wine Only, etc. Beauty---Spa Service---Hair Removal, Lasers, etc. But The KEY to your success is your Workflow and using Conditions! For my users, I have them go through several slides where they pick from a MultiDropdown list of Static Choices starting with their Category(ies). Based on their answer I have Workflows set up to take them to the next slide. If, say, they only choose Food/Drink and Beauty as their Categories, the next slide will only display the Services associated with Food/Drink and Beauty. And then the following slide only shows Specialties that are associated with the Service. As your Users navigate through, you'll have setup Workflows to save their choices each time they hit the 'NEXT' button. Let me know what you come up with! Cause I'm sure there are simpler ways to make it all make sense, but, for me, this was the best way I could create relationships between levels with more than 2.

[@thinusenslin]

Thanks for the video! How would you handle large static datasets? I have a static dataset that is 10 categories wide and 8.5k rows deep. Using the Bubble db to create dropdowns / repeating group (for selection) is very slow. I have implemented Xano which is faster but it still takes about 10 seconds to populate the dropdowns / repeating groups. That’s why option sets sound perfect due to its speed.

[@coachingnocodeapps]

I wouldn't use option sets for 8K+ options because you can't import options, and you probably don't want to add those in manually! (Let alone edit them if needed). The interface just isn't suitable for large datasets. So, I'd stick with the database for that. You could try creating separate types per category to break it up a bit and improve the load speed.

[@dispiff]

Please I'm very curious to know if bubble has a feature tha allows me automate a task like searches and clicks on an external website that possibly does'nt have an API?