When you create your database tables, you should have the options to select option types, this will allow you to assign option values to data types.
1 Like
Sure thing 
, but it would be really nice to have a better view in the Option Sets themselve. At the moment its the options sets on the left as a list, with a huge width and then on the right are the fields and entries squashed up with just the ‘Display’ field visible, no other fields visible to reference. So if we use vague ‘Display’ field values and more contextual ones on other fields, we have to jump to the edit window in each to check.
It would be nicer for a better balance in widths and the option to have a few more fields visible for the Option Set entries - hopefully the revised editor covers this inbalance or limited view of things.
3 Likes
Replying to myself.
Bubble’support confirmed that sorting as mentionned above (or in the pic downhere) is not yet possible.
I used custom attribute to rank them and be able to compare something with :
:filtered “status”>Option sets’Ranking
Where ranking is my new custom attribute, whose values are 1, 2, 3…, following the chronological status of the Thing.
Hope Bubble will allow to change that sorting in the future :
Michel
1 Like
(and to access the custom attribute in the :filtered parameter, you need to use “Advanced”).
Thanks for this,
I have a question about security, privacy, when using it …
I have a type of data, with field that can have 5 different « status » : draft / pending / accepted / canceled/ declined
Let’s say this is a home rental platform. (of course it is an example, I am not feeling like competing with airbnb 
)
So The Data is « Booking », so option sets could be draft / pending…
And I have an other data type with a « list of booking », for example « home »
What I need is that when a user create a booking it’s « draft » by default, when he confirms it It becomes “pending”.
And, when the home owners accept the booking it becomes « accepted ».
And so on…
I did this before with a lot of “yes/no” data field and sometimes it’s a nightmare as you have to modify different field at the same time.
Do you think option sets would be the best option for it ?
I read we cannot applied privacy rules to Option sets. And so, I was thinking this is not secure to do it this way ?
Still I can have privacy rules regarding, in this example, “Bookings” and “Home”. That’s what you mean right ?
So no issue to do it this way ?
this would save a lot of time to me and speed up the app 
Thanks a lot !
Is there not a way to change the value of an attribute of an option through workflow?
Just posted a suggestion for a minor improvement to option sets which I think would make them more useful over here: Extended Option Set Comparison
If you think the idea would be useful, feel free to signal it so bubble’s team is made aware of it.
@aghanasirazeemi9 no there is not. Option sets are inherently static, i.e. they do not change unless the app developer changes them. If you need attributes that change, you can use a custom data type in a similar way.
1 Like
I know this is probably late, but at the very least anyone reading this might be helped.
You can use option sets as fields on Things in data. So you could put a “status” field on the User (or Home Owner) Thing. You can set the default value of this field to the option you want, and update it via workflows.
You CAN set privacy rules on the field by setting the privacy rules of the Thing that the field is on. This means that you can control who sees a given homeowner’s status. What you CAN’T do is set privacy rules on the option set ITSELF. This means that anyone who uses the app can theoretically see all of the potential statuses that a homeowner COULD have, though they can’t be changed by the user due to the nature of option sets.
I know adding option sets to the searchbox was in high demand, myself included. Has this been implemented yet?
1 Like
It helps,
many thanks 
Hi @cal
Please can you confirm if the Option Sets are loaded on a specific page when referenced or loaded across the site as global values - in the frontend? Also it would be nice to contextualize the performance between hard coded values e.g. from an element on page compared to data pulled from an option set.
Thanks
2 Likes
Hi @luke2,
Option sets are delivered with page load, alongside other parts of your application (elements, app text, workflows, etc.), so they don’t require an extra search when comparing, say, a text element referencing an option set to a text element with text. The only thing extra is a lookup in a JSON object, which is very fast and done on the client, so shouldn’t be a noticeable speed. change. Feel free to run speed tests but in my testing I couldn’t perceive a loading difference between the two.
Between option sets and app data, however, there most definitely is a speed increase, as unless the data was already pulled in a previous search and saved, we need to get it from the server, resulting in a search. The one exception is referring to “This page’s thing”, which we actually send with the initial page load.
When in doubt, you can monitor the “Network” tab of the chrome debugger on your page to see outgoing network requests we make. You may see calls to “msearch” or “bulk_watch” or similar, and these are searches for things. Option sets won’t incur these extra searches.
6 Likes
Hi,
is it possible to import an option set from a CSV?
3 Likes
Hi @cal, could you clarify this answer a bit more. Specifically:
-
When a page loads, does it load ALL of the option sets in the app, or does it only load the option sets needed for a specific page’s functionality?
-
We understand that once option sets are loaded, the page should be faster because option sets reduce the need for searches. However, is there any material increase in the initial page load time related to using an option set? (Logically there would be some increase in page load time, because option set data is being loaded in).
I think users are still looking for clear answers to these questions. For example the below post.
thank you
3 Likes
I might be wrong, but I think @jason1 was referring here to the potential for option sets to enhance SPA’s that are rendering UI dynamically based on the URL structure. For instance, I’m in the process of building a single page application (using @sudsy’s excellent Sudsy URL Routing plugin) that will rely on option sets to tell my app which UI modules to render for a given URL “view,” as well as what SEO metadata to show search engines. Each URL corresponds to a “view” record that is stored as an option set. This record contains all of the modules that are to be rendered on the page. When the URL changes, a workflow is triggered that will look up the current view and save it as a custom state on the page. Without option sets, I’d have to call all that data from the server, which would affect performance quite a bit.
@cal any chance you can help clarify this?
@cal Any word on support for :sorted and “do a search by” using option sets? Its a popular feature request and would be extremely useful
Edit: To clarify, I mean using the option set as the field to sort upon
1 Like
Hi @cal
I’m using more and more Option Sets.
Is there a risk of slowing done the page load if we use something like 20 tables of option sets with about a dozen of option in each ?
Is the JSON with the option sets loaded once or refreshed at each page load ?
1 Like
Ok, good to read this 