Hello! I’m trying to figure out how to link a response from a buyer to a specific product in seller inventory. How I have it set up is the Buyers can see every product available, from all sellers. This is in a repeating group with a button to “purchase” or “bid”. How do I set up the bid where it sends the information on the bid to the seller that created the listing but for only that specific product, assuming the seller has multiple products. Any insight/advice would be very much appreciated. Thank you!
Welcome to the Bubble Community! 
I can see where that might be confusing.
Can you share a screenshot of what you have so far? Do you have a button inside the repeating group? Or when you click on it does it show a popup that has the data?
Let us know. 
Hope we can assist.
1 Like
You can create a data type Bid with following fields:
- Buyer (User)
- Seller (User)
- bidAmount (number)
- Product (Product)
- isAccepted? (yes/no)
You can create a new bid when a buyer clicks on the bid button in the repeating group. I won’t recommend using a list of Bids on the Product and incrementing that. Many reasons for not doing it, one of them is Bubble has 10K hard limit on lists meaning it won’t save > 10K items in a list
Instead on seller dashboard you can render the list of Bids by doing a search with following constraints:
Product = Selected Product
Seller = Current User
I hope this helps
1 Like
I’ll try this - thank you so much!
@elizabeth.bonnie80 Seller is NOT current user. Seller is Product owner, the Current User is bidder/buyer.
Likely, your product is created by the seller, so you may just currently be relying on the built in Created by field bubble attached to each entry in the database of every data type. That created by field is a User, and User data type has an email address.
Depending on your ultimate goals you may need to do more to save bids, but just for purpose of sending info to the seller, you can reference, selected product created by email in a send email action. Have a popup as mentioned in other response for elements needed to input a bid and submit which will run action to send the email.
The key is storing a reference to the specific product (Thing) on the bid record itself.
When the buyer clicks “Bid” on a cell in the repeating group, create a new Bid record and set a field (e.g. “Product”) to Current cell’s Product. Also store the bid amount, the buyer, and you can pull the seller directly from Current cell’s Product’s Seller — no need to set that separately.
Then on the seller side, show a repeating group of Bids where Bids’s Product’s Seller = Current User. Each bid already carries the product reference, so the seller can see exactly which listing it’s for.
Quick checklist:
- Bid data type has fields: Product (type: Product), Amount (number), Buyer (type: User)
- “Create a new Bid” workflow on the button uses Current cell’s Product for the Product field
- Seller dashboard RG filters Bids by
Product's Seller = Current User
Does your Product data type already have a Seller field pointing to the User who created it? If not, that’s the first thing to add.
1 Like
@boston85719 if a Bid has both Seller and Buyer fields (of User datatypes) then on Seller dashboard how will you render the list of bids? Wouldn’t it be using Seller = Current User?
You’re right. I didn’t read that was for seller dashboard search constraint to search all bids. I thought it was for sending bid info to the seller when a bid was being made.
1 Like
Got it @boston85719
As you mentioned the built-in ‘created by’ field I have a question about this: is it a bad practice to use Created By field? I always save a separate reference of User since Created By is immutable and in some scenario an Admin might be creating something.
Yes, on a whole it is. I normally put a field called User Owner and make that the field that is for the actual user (never admin - actual owner of the data). Because sometimes you may have an app that is for a company, and the employee who created the data leaves the company, and you need to transfer the data to another employee, or as you point out an admin creates the data on behalf of a user.
In some apps though, like a e-commerce app in which it can reasonably be expected the creator of the product is always the actual product owner as a user, and that admin will not create products on user behalf, nor would products need to be transferred to other users, it is fine to leverage the built in field of created by since it is already there.
It is just a matter of thinking through the app, its features and whether or not a new field for a User relation is needed or not.
1 Like
Got it. Thanks for explaining @boston85719