Automate "update" on automated created record

[steven_wan]

form to insert record in view

information in tab1 view A, will be carrier over to tab 1 view B (1B) ,(using filter to only have wanted info
use airtable automation to create new record in tab 2 view A (2A)
up to here no problem, all info will be carrier over

but when need to update or change information but cant carrier over.

-so i use automation trigger " update the from view 1B", tested no problem

action update to 2A, but keep having the problem at here. test → record does not exists.
-record id = airtable record id

how to solve this problem
intend is that using the form it will create a new row information.
but when need to edit/update the row info on 1A, or 1B, it will sync over to 2A.

[JonathanBowen]

Hi @steven_wan - I think the issue here is that you are trying to update a record in Table 2 with a record id from Table 1, hence it does not exist.

On create, there’s no issue because you have data in table 1 and you simply create a brand new record in table 2.

However, on update of a record in table 1 you need to know which record in table 2 is the right one to update. There’s two ways to do this:

• In the update automation, the actions part will be 2 steps. You’ll end up with:

Update record in Table 1 => Find record in table 2 (based on info from record in table 1) => update record in table 2

• The other option is to explicitly update the record in table 1 with the matching record in table 2 when you create the record in table 2. So here (on the create automation) you have:

Create record in table 1 => Create record in table 2 => update record in table 1 with record 2 ID

Now on the update automation, you already have the ID of the record in table 2 that you need to update.

Which option you go for will depend upon your specific data, base design, use case and so on, so maybe try each on out and see what works best for you.

[steven_wan]

hi, is it possible to contact you on email to chat about it? i used option number 2. but my issue is i cant match the record.

is to do the automation within 1 automation or is a split automation?
also i dont get the point of " update record in table 1 with record 2 ID"

which ID is to key in? because
1st is to choose the “table”
2nd is the ID, which my case is just 1 option from the 1st table (original)

my intention is to have the record automatic update to 2A when it’s being updated in A1

[Kamille_Parks]

If record values in Table 2 are supposed to always match record values in Table 1, why not just link the two records together? You could use Lookup-type fields in Table 2 to pull in values from Table 1. This eliminates the need for an Automation to sync values together, you’d only need an Automation to create the Table 2 record, which you already seem to have functioning.

The full process would be something like this:

Trigger: When record in Table 1 enters a particular view.

1. Step: Create record in Table 2. Instead of filling in each individual field that is supposed to match, fill in a single Link to another record-type field with the record ID from the trigger record.

[JonathanBowen]

Yes! Of course! This actually makes more sense

[Chantelle_Nash]

This is definitely an easier solution to seamlessly keep the records updated/connect, as I couldn’t get any of the others to work. That said…I have records in my Table 2 (the target table for my synced records in Table 1) that were created directly in that Table 2.

Unless I’m missing something, this seems to create a bit of a mess if I want to have a view that shows records from both sources, since my Table 2 will now contain double/duplicate columns (the original columns built into that table, and then the synced/lookup column fields from Table 1). Or is there a way to avoid this?

[Kamille_Parks]

Well now the question is: Why do you need two tables? Do you need two tables?

[Chantelle_Nash]

From a purely logistical standpoint, no. I completely understand what you’re saying. But we are collaborating with others who have their own bases that are set up to be simple for them, with other tables they need that we do not. Our base also has several tables and views they do not need.

Also, while they have the data we want in their base that aligns 1:1 with fields in ours, they also have several other fields in their tables to capture data in their base that we do not need in ours. So to have them work in our base would then require us to create fields that the rest of us would not use, again making things a bit messy.

But having a consolidated view for the full picture of overlapping projects that involve our team is a nice thought.