Let's set the scene here. We want our trips to have something called a Trip Type. One trip type might be a solo trip that users take. Other ones might be a friends-and-family type of trip.

Not only do we want to display those types in the interface, but we also want to let the user filter by them. This feels like another kind of data relationship, where multiple trips exist in our database and some trip types like solo, family, or business are attached to particular trips.

Maybe these first two trips are solo, the next two are family, and the last one is a business trip.

The structure of this relationship is similar to what we've seen already, where multiple diary entries are connected to a single trip or multiple trips are connected to a particular user.

But there's something different about trip types. I don't want these to be things that my users create. I want to define the master categories—the master trip types—myself.

In Bubble, we set these trip types up not as another data type but as an Option Set.

To understand an option set, think back to the beginning of the course where we distinguished between the Front End (Client), which is the user's device, and the Back End (Server), which is where our database lives.

Option sets are similar to data types, but they live on the front end as part of the structure of your application, rather than in the database.

The different options—business, solo, friends and family—are defined by us, the application developer, not by the users.

Option sets are useful because we might want to:

To create an option set in Bubble, go to the Data Tab, click on Option Sets, and skip the tutorial. Then define the name of the option set—for example, Trip Type.

On the right-hand side, create the Options in this set. These are the entries on the “Trip Type shelf.” Examples include:

Next, create a relationship between trips and the option set. On the Trip Data Type, add a new field called Type, and point it to the Trip Type Option Set.

On the create/edit trip form, add an input for selecting the trip type. Duplicate an existing input group, delete the old input, and amend the label to Type.

Add a Selectable List input inside the group.

A selectable list works similarly to a vertical list. We define the first row, which is then replicated for all other rows. Change the item label to Type.

Set the selectable list to allow selecting a Single Thing (or multiple if desired). The data source should be Dynamic, with type Trip Type, and source All Trip Types.

Set the text inside each list item to show the Display Value of the current trip type.

Testing the form shows all trip types available. Selecting one sets it as the Selected Choice, which can be saved to the Trip Type field in the database.

Option sets also support Attributes (like fields in a data type). For example, you can add a Description attribute for each trip type.

Selectable lists have a built-in Selected Property, allowing conditional formatting. For example, change text color when an option is selected.

When creating or editing a trip, store the selected choice in the Type Field for that trip.

You can also display trip types in the Trip Details View. Add a text element, pull the Display Value of the trip's type, and use conditional formatting to color-code the trips.

For example:

Now, the basics of option sets are in place. In the next lesson, we’ll start building filter logic so we can filter trips by type.