What I’m calling a “list” field contains foreign keys. As you’ve probably seen, when you create a new field in Bubble, you get a bunch of options like text, yes/no, date, etc, but also it shows you all the other datatypes (ie tables) you’ve already created. So you can select one of those to link entries to an entry or entries in another datatype. That could be a single reference, or if you pick “This field is a list”, then multiple references. You don’t need to tell Bubble which field in the other datatype to use to create that link; it does it automatically (though you can define which field Bubble shows for that datatype, by picking the primary display field).
In your case, if a Post can only be marked complete once, I’d avoid the intersection table and just create a field within Post with the completion data and the User who completed. But if a Post can be completed by multiple users on multiple dates, then you may have to go with the intersection datatype. I think the intersection datatype’s fields would be:
- Unique id (this is a field Bubble automatically creates and populates)
- Created By (this is an automatic field that Bubble creates and populates with the logged in user who creates an entry)
- Post (you need to create this field and select Post as its type)
- Created Date (this is a field that Bubble creates and populates automatically)
Per above, if your user is logged in, then the only field you have to create in the intersection datatype is Post. The rest Bubble automatically creates.
One final thing – I’d recommend some reading and experimentation on Bubble search/display. Ideal data structure in Bubble can’t be decided in a vacuum – it depends somewhat on how you plan on searching and displaying the data. So build out your search/display functions and test it on some dummy data to ensure you’re happy. This post is required reading in my opinion because it explores a lot of the considerations: