Bubble.io Option Sets: What They Are, When to Use Them and When Not To

Updated October 2026 · By Athar Ahmad, certified Bubble.io developer and founder of SA Solutions

Option sets are one of the most useful features in Bubble.io, and one of the most misused. Used well, they make apps faster, cleaner and easier to change: statuses, roles, categories and plans all become consistent everywhere. Used badly, they can expose information that should be private. This guide explains what option sets are, the best ways to use them, how they compare with data types, and the one rule you must never break.

What option sets are

An option set is a fixed list of values you define in the editor’s Data tab, such as Order status with options Pending, Paid, Shipped and Cancelled. Fields can use an option set as their type, so an Order’s status can only ever be one of those values. Because option sets are loaded with the app, they are available instantly, without database searches.

Attributes

Each option can carry attributes. A Status option might have a display label, a colour and a sort order; a Plan option might have a price ID, a seat limit and feature flags; a Role might have permission flags such as can edit or can delete. Your interface and workflows then read these attributes, so a change in one place updates the whole app.

The best uses for option sets

• Statuses: orders, bookings, tasks and tickets
• Roles and permissions: role names with permission flags; see role-based access control in Bubble.io
• Plans and feature limits: plan names, limits and Stripe price IDs
• Categories and types: fixed lists such as industries or property types
• Navigation and settings: menu items, tabs and app-wide configuration
• Countries, currencies and languages

Option sets vs data types

The security rule: never store sensitive data in option sets

Anything private belongs in a data type protected by privacy rules, and secrets such as API keys belong in private API Connector settings.

Practical tips

• Add a sort order attribute so dropdowns appear in a sensible order
• Use a display attribute for the label shown to users, so internal names can stay stable
• Avoid deleting options that existing records use; mark them inactive with an attribute instead
• Use option sets in search constraints and repeating groups for fast filters; see repeating groups
• Remember that option set changes go live only when you deploy

For how option sets fit into your wider data structure, see Bubble.io database design.

Frequently asked questions

What is an option set in Bubble.io?

An option set is a fixed list of values defined in the editor, such as statuses, categories, roles or plans. Each option can have attributes, such as a colour, label or permission flag, and option sets load instantly without database searches.

When should I use an option set instead of a data type?

Use an option set for fixed lists that only you change, such as order statuses or user roles. Use a data type for anything users create or edit, anything that grows over time, or anything private.

Are Bubble.io option sets secure?

Option sets are sent to the browser so the app can use them instantly, which means anyone using the app can read them. They are perfect for labels and settings, but you must never store sensitive or private information in them.

Do option sets use workload units?

Option sets are loaded with the app rather than searched in the database, so using them does not require database searches. This makes them faster and more efficient than equivalent data types for fixed lists.

Can users add new options to an option set?

No. Option sets can only be changed in the editor, and changes go live when you deploy. If users need to add their own categories or tags, use a data type instead.