I'm trying to use an automation in a base, but there's something wrong with my flow. And it may be that what I'd ultimately like to accomplish isn't possible.
In Base 1, I have a single-select field named "Status" with various color-coded options as variables to select from. In Base 2, I have a duplicate of the fields in Base 1, but none of the data.
My goal: When the single-select field Status is changed to a particular option (in this case, "Delivered"), the record is copied from Base 1 (Active) and duplicated in Base 2 (Archive). But the flow I have is definitely not correct.
So, one, is this possible? And, two, does anyone know what I need to adjust in the automation flow? Thanks so much for your time!
Best answer by Alexey_Gusev
Hi, Usually storing similar entities (records with the same set of fields) in different tables considered as bad design in Airtable. Instead, they should exist in a same table, with a set of filtered views to the different sets of records. But in your case, you want it to be in other base. So, automation will not help you with that, as the scope of automation is the same base. The tool that suitable for your case is syncing. You can create a view with a limited set of visible fields (hide fields that you don't want to be synced), then filter it to see only 'Delivered' status, and sync that view to another base. Thus, each time new record became 'Delivered', it will be synced to the Base2. If you plan to remove these records after and you want to preserve them in the Base2, just change this setting
I would also recommend to lock the view afterwards and set some warning to avoid accidentally breaking your sync configuration.
You'll need to add every individual field that you want data to be duplicated in to. And on top of that, you'll have to configure each field to populate with data from the trigger source.
It could be quite time-consuming to go through each field if you have hundreds of fields. in addition, if you made a new field in the first table, you'd have to add that and configure it in table 2.
There could be a simpler archiving solution than using another table.
Hi, Usually storing similar entities (records with the same set of fields) in different tables considered as bad design in Airtable. Instead, they should exist in a same table, with a set of filtered views to the different sets of records. But in your case, you want it to be in other base. So, automation will not help you with that, as the scope of automation is the same base. The tool that suitable for your case is syncing. You can create a view with a limited set of visible fields (hide fields that you don't want to be synced), then filter it to see only 'Delivered' status, and sync that view to another base. Thus, each time new record became 'Delivered', it will be synced to the Base2. If you plan to remove these records after and you want to preserve them in the Base2, just change this setting
I would also recommend to lock the view afterwards and set some warning to avoid accidentally breaking your sync configuration.
Hi, Usually storing similar entities (records with the same set of fields) in different tables considered as bad design in Airtable. Instead, they should exist in a same table, with a set of filtered views to the different sets of records. But in your case, you want it to be in other base. So, automation will not help you with that, as the scope of automation is the same base. The tool that suitable for your case is syncing. You can create a view with a limited set of visible fields (hide fields that you don't want to be synced), then filter it to see only 'Delivered' status, and sync that view to another base. Thus, each time new record became 'Delivered', it will be synced to the Base2. If you plan to remove these records after and you want to preserve them in the Base2, just change this setting
I would also recommend to lock the view afterwards and set some warning to avoid accidentally breaking your sync configuration.
Really interesting! Thanks so much for this recommendation!
