Help

Re: Mix synced records and manually created records

Solved
Jump to Solution
1765 0
cancel
Showing results for 
Search instead for 
Did you mean: 
Anthony_Fransel
5 - Automation Enthusiast
5 - Automation Enthusiast

Hey there! I’m syncing some records from Base 1 to Base 2, and that’s working just fine. In Base 2 I need to be able to add additional records alongside the synced ones. I set up an automaiton to copy these new records over to another Table in Base 2, which works perfectly. I was then trying to use an Update Record automation to copy changes, which tests fine but fails in practice with an error. Is that possible, or is there a better way to accomplish this?

I was using Find Records with a condition of my manual unique ID (not the Airtable Record ID), which it seems to do, and then try to apply the updates to the Record ID from that step (Step 2). It all says it’s good, and can even update it from “Run As Configured” - but it fails when I test it by updating Base 1 and syncing Base 2. Updates fine in the sync but fails to update the record in that second Table. Thanks!.

1 Solution

Accepted Solutions

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 & B), but it works! :grinning_face_with_big_eyes:

See Solution in Thread

4 Replies 4

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:

  1. 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.

  2. Writing your own custom Javascript script that communicates across both bases.

  3. Using an external automation tool like Make.com that communicates across both bases.

Anthony_Fransel
5 - Automation Enthusiast
5 - Automation Enthusiast

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 & B), but it works! :grinning_face_with_big_eyes:

@ScottWorld With this approach; can fields be updated in any base