​@Inertia 

That is not really the ideal way to setup your base.

The best way to setup your base would be to just have one table of your bids (regardless of whether they are confirmed or not), and just add a status field that shows whether the bid has been confirmed or not.

Then, if you only want to see the confirmed bids, you can use filtering, views, or filtered interfaces to show you only the confirmed bids.

Hope this helps!

If you’d like to hire the best Airtable consultant to help you with this or anything else that is Airtable-related, please feel free to contact me through my website: Airtable consultant — ScottWorld

How does this look?  I’ve set it up here for you to check out

The idea is to link the bid to that new record that gets created on confirmation:

That would allow you to use that linked record ID for the automation like so:

I assume you need to be able to manually update the fields in Tbl_Confirmed, and that’s why you can’t use lookup fields to just display the data instead?

I’m also kind of curious as to your workflow, does Tbl_Confirmed have a ton of processes / fields that aren’t relevant to the bidding process, and that’s why you separated it into two tables?

How does this look?  I’ve set it up here for you to check out

The idea is to link the bid to that new record that gets created on confirmation:

 

That would allow you to use that linked record ID for the automation like so:

I assume you need to be able to manually update the fields in Tbl_Confirmed, and that’s why you can’t use lookup fields to just display the data instead?

 

I’m also kind of curious as to your workflow, does Tbl_Confirmed have a ton of processes / fields that aren’t relevant to the bidding process, and that’s why you separated it into two tables?

Hello Adam, 

Thank you for your reply and your help! Tbl_Confirmed is meant to be a filtered version of Tbl_RFQ. This is because Tbl_RFQ is meant to aggregate all the bidding data. For example, in one instance, an item may invite 3 bids. This means 3 records in Tbl_RFQ. If a bid is accepted then only 1 record will be created in another table. After multiple iterations, this will serve as a history of successful. I could just put everything in one table (for sure) by creating a tick field called “Successful bid”. However, my colleagues are not tech-savvy (we are based in developing country) so they will get confused by this. So the reason behind the simple table structure is due to limited human capital and limited human personnels. So I really try my best to simplify the work processes for them. 

Warm regards,
Yanith

 Good day Adam, 
I am not entirely sure why. I followed your step in linking the two tables together. However, the error says received invalid input. The first “When record matches condition” works. However, the second type does not work. It appears that the record ID is “linked” somehow. 

I have also tried this other variation, but it also does not seem to work. 

Hmm, could you provide some screenshots of your tables?  Would love to help but need more info I’m afraid.  If you could DM me a link to your base that’d be great 

Try updating the automation to use the Record ID instead!