Airtable doesn’t yet allow two-way syncing, so there’s no native built-in way of updating or adding records back in the source table. You can always add a button field in your destination table that opens up an existing record in the source table, so that’s a quick way of jumping to the source table to update a record. And you can create a new record while you’re there.
(Note that you can add your own additional fields in the destination table that live in the destination table, but you can’t add new records.)
Airtable’s native automations only allow you access to the current base, not any other bases, so you would need to come up with some other way to update/add records back in the source table.
Some popular methods involve:
Creating a form in the source base (that you may or may not prefill with values that you get from the destination table), and then upon form submission, that would either add the records into your source table — or you could create an automation in the source base to automate an update.
Writing your own custom Javascript script that communicates across both bases.
Using an external automation tool like Make.com that communicates across both bases.
Thanks Scott!
So I was actually looking to auto-update another Table in the second Base, rather than loop back up to the first Base. However! It looks like a workaround might be to have a second copy of each field (so, Status is synced and Status 2 is updated automatically to match Status) and then copy then to the new Table. It didn’t seem to like me copying over the synced value to a new table but it doesn’t mind copying it to a new field in the same table.
Update: and now I seem to have been able to get it to work without that extra field. Only thing I did different was include the update in the same step as find records.
Thanks Scott!
So I was actually looking to auto-update another Table in the second Base, rather than loop back up to the first Base. However! It looks like a workaround might be to have a second copy of each field (so, Status is synced and Status 2 is updated automatically to match Status) and then copy then to the new Table. It didn’t seem to like me copying over the synced value to a new table but it doesn’t mind copying it to a new field in the same table.
Update: and now I seem to have been able to get it to work without that extra field. Only thing I did different was include the update in the same step as find records.
Yes, that’s a clever trick that I didn’t think about — natively syncing in a circle:
- Table A in Base 1 syncs to Table B in Base 2.
- In Base 2: Airtable’s native automations can communicate natively between Table B in Base 2 and Table C in Base 2.
- Then, Table C in Base 2 syncs to Table D in Base 1.
- In Base 1: Table D in Base 1 can be natively automated with Airtable’s Automations to communicate with Table A in Base 1.
Of course, you’ll end up with 4 tables (A, B, C, D) instead of 2 tables (A &
, but it works! :grinning_face_with_big_eyes:
Yes, that’s a clever trick that I didn’t think about — natively syncing in a circle:
- Table A in Base 1 syncs to Table B in Base 2.
- In Base 2: Airtable’s native automations can communicate natively between Table B in Base 2 and Table C in Base 2.
- Then, Table C in Base 2 syncs to Table D in Base 1.
- In Base 1: Table D in Base 1 can be natively automated with Airtable’s Automations to communicate with Table A in Base 1.
Of course, you’ll end up with 4 tables (A, B, C, D) instead of 2 tables (A &
, but it works! :grinning_face_with_big_eyes:
@ScottWorld With this approach; can fields be updated in any base