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