Forum Academy Marketplace Showcase Pricing Features

Check box Matrix grid

Hello all ,
Im new to bubble and absolutely loving the potential.

Im currently attempting to create a multi select checkbox matrix grid as per this :

Each user will be able to choose what service or sub service they can provide in which region

Maybe the great minds here can guide me with my two fold question:

  1. Assuming the options will stay fixed, whats the best best way to structure my database : Data Types for each category, sub category and region . or Option sets for each.

  2. Should these checkboxes be inside repeating groups and whats the best way to reduce workflow steps needed to save this information for later use?

Thank you in advance for any tips


Hi Rajai,
I’ll have a go. One thing that will make it a lot easier is to design your database so you can use auto-binding. (That’s a feature to automatically save changes and display the state of the check boxes without creating workflow). Google for help on Bubble auto-binding - many references explaining it, find one that explains it at your level :slight_smile:

Whether to use options sets or reference tables … really depends :slight_smile: . Option-sets seem enticing (because they are always mentioned with “performance”) . But have some drawbacks. I’d avoid options sets if

  • your options could change
  • you ever want to sort by the option set value or attributes ever
  • anything about the option set is something you don’t wish to be public (options-sets are 100% publicly visible)
  • you ever want to export your data to a CSV file or use the Bubble App connector

So if it was me I would have a table called something like

Service Preference

with columns

Category (text)
Sub Category (text)
Region 1 Yes/No
Region 2 Yes/No
Region 3 Yes/No
Region 4 Yes/No
Region 5 Yes/No

Yes - I would denormalise Regions - makes it easy to implement and auto-bind in Bubble
Yes - I would treat categories as Texts (not a type) - so I can easily sort and search by category.

If that numbering of the categories was a requirement and other was an order that wasn’t alphabetic - I would additionally add two more columns of types
Category order (number)
Sub Category order (number)

And append those together on the UI to give you x.y 2…1

One personal lesson I have had with Bubble is to leave behind your purist Traditional Relational Database design ideas. :slight_smile: But the benefit of Bubble is that then modelling all of this and getting it working (with a bit of practice and experience) can make implementing all of this, including the UI into a matter of minutes.

Good luck!


@lindsay_knowcode : Amazing insights and guidance, ill check it out today , allow me to bother you again if i get stuck.

Thank you