Forum Documentation Showcase Pricing Learn more

Lots of little checkboxes!


I’m creating a form that has a lot of checkboxes to indicate things like:

Payment Types (check all that apply):

  • credit card
  • cash
  • gift card
  • debit card
  • etc.

I’m a bit confused on the best way to store this in the database. For my workflow for the Submit button, I have it create a new Listing object, which has fields like Name, Address, and Payment Types.

What field type should the “Payment Type” be? I’m guessing Yes/No and then using the “This field is a list (multiple entries)” checkbox. But I’m having a hard time choosing the right options to store the data.

Any advice would be appreciated!


You might want to think about just storing these as an array of “Payment Types”. So have a thing which has all your payment types on it, then on your Listing thing, have a “list of payment types” that is populated with all those the user has checked. So the Type would be “Payment Type”. Then tick the list option.

Saving the states of a bunch of options is a little bit fiddly, but there are plenty of topics about this.

Hey, thanks Nigel. I actually asked Emmanuel via email and this is what he said:

“Then the best way is to store the currencies is to have a field as a list of texts, and add/remove the entry when the checkbox’s value is changed (use a condition on the event to see if you should add or remove).”

To which, I tried this:
When the big Submit button on the form is clicked, it creates a new object of type “Exchange.” Exchange currently has two fields called “Name” which is text, and “Payment Methods” which is a list of texts as you suggested. Then I added all the relevant checkboxes for Payment Methods.

But that’s not quite right. So I’ll let Emmanuel chime in. Thanks!

What I would do is for each checkbox, you can say"

when th checkbox USD is changed, and when checkbox USD is checked -> Payment methods add ‘USD’

when th checkbox USD is changed, and when checkbox USD isnt’ checked -> Payment methods remove ‘USD’

So don’t have all things in one workflow, but in more than one.

Do you think your method is still the best way even though this is a one-time submission form?

Yes, What is the difference if it’s a one-time thing?

Ah, only because I’m trying to determine exactly what you mean by “when the checkbox USD is changed, and when checkbox USD is checked -> Payment methods add ‘USD’”

I think I’m confused because I thought the object “Exchange” is only created upon clicking the giant Submit button on the form. If I create a trigger based on the check/uncheck action, does that make sense if the object “Exchange” hasn’t been created yet? Or maybe I’m just very very confused here.

Thanks for your help! -John

I think doing it this way means that you would have to create the “Exchange” object on page entry, and then modify the currency list array as each check box is changed.

If you add them all at “Create” time as you have done above, using “is checked” then you will get a list that looks list yesnononoyesnoyesyesyes … which isn’t that helpful I don’t think. When really what you want (I think, correct me if I am wrong) is a USDCADGBPEUR list ?

As it stands (although development is rapid and this may have changed) we don’t have a way to say …“If this checkbox is checked then put USD in this field” … for a list of fields. We have to store the “list” somewhere each time something changes. Currently the best place to put this is on an object using it as temporary storage.

Thanks, Nigel. But I think if it creates a new “Exchange” object on page entry, the database will quickly fill up with irrelevant data. This will be a high traffic website, so that probably wouldn’t work unless there’s some sort of protection against this that I’m failing to see?

I guess one of the reasons I’m confused is because I’m trying to store the value of the checkbox (in yes/no format), and in this tutorial video that seems possible (at 3:14):

But in my app, that option doesn’t exist:

The “value” of Negotiable is still Yes / No though, not anything else. I think that may be an older UI, as now you can set yes / no as to whether it is checked or not (i.e. not every check mark can mean "Yes).

In terms of redundant objects, people have created them with a status “pending” (or similar) and then updated on pushing the “Big Button”. You can then have an admin panel button to delete all pendings.