I am a fairly recent arrival to the bubble user community and so beg your forgiveness if this is a dumb question. I recently ran into a problem with a backend workflow that made me conclude (correctly???) that the issue was with my use of Option Sets (added detail - was referencing to reference a numeric attribute of Primary Option Label).
I ended up replacing the Option Set with a Custom Data type and it appeared to fix the issue but my lack of discipline in development (ie. I changed too many things at once to be sure that was the issue) makes me uncertain of that conclusion.
1.) Are there any issues/limitations to using Options Sets in Backend Workflows.
2.) Is there a more detailed pro’s and con’s analysis of Option Sets vs Customer Data Types.
This second ask would hopefully answer an advantages question I have about deployment. Is it safe to assume that Option Sets are the same in both test and live versions - in contrast to Custom Data Types which I believe I have to take special care to ensure are the same in both.
Deciding to use option sets or custom datatypes will largely depend on what you’re using them for. To answer your questions…
Not especially. Obviously option sets and datatypes are not the same thing, so you can’t use them in exactly the same way. But there’s no specific limitations on using them in backend workflows compared to using them elsewhere. (did you have any specific limitation in mind when asking the question?)
Generally using option sets will be faster, as there’s no need to access the database (which may not be an issue in a backend workflow). Option sets don’t have privacy settings though, so shouldn’t be used for sensitive data.
Here’s a few more comparisons (taken from Bubble’s Manual):
Comparison vs. Custom types
It’s technically possible to get many of the benefits of option sets using normal custom data types. You should consider option sets instead for a few reasons:
Options are faster to access, as they require no database reads
Options sets are easily extensible to add new options and change existing ones. Renaming an option will propagate throughout your app.
Options sets are easier to use. They can be accessed from anywhere in your app, and are a lot easier to access than doing a search.
However, there are a couple of downsides compared to custom types:
There are no privacy settings for options. So, do not put sensitive data as an option’s display or one of its attributes.
To add new options or change existing ones, you must push a new version of an app, unlike regular data which you can add while your app is live.
As to your last question, yes - option sets are the same for all versions of your app, so there’s no need to copy database entries etc. from dev to live before you publish.
You can read more about option sets in Bubble’s manual:
re. specific example/use - I was wondering if referencing Option Set attributes was not possible in backend workflows ever or only in certain circumstances.
Thanks for the explanation on the deployment implications. Very useful intel!!
