I’m writing a script that where I need to identify if a record has been deleted or not based on the recordId. From what I can tell a deleted record doesn’t return any values identifying its active state in the record object when using the selectRecordAsync() function.
For others searching for this who are looking for a non-scripting way of doing this, there is an undocumented hack that can accomplish this by using Airtable Sync.
I gained this knowledge from @Justin_Barrett, who was the first person that I know of to discuss this hack:
Take the view of source records that you want to monitor for deletion, and sync them to a destination sync table.
In the destination sync table, select the option to keep deleted records after they are deleted from the source table.
Airtable only gives us ONE HIDDEN WAY to tell if a record has been deleted from the source, which is to create a button field that opens the source record. This button will appear visibly active when the source record exists, and this button will visibly dim to let you know when the source record has been deleted.
However, we can also create a formula field that is equal to the button field. This formula results in the URL of the source record when the button is active, but the formula results in nothing when the button is dimmed.
So this formula is what you would use to determine whether the source record still exists or has been deleted.
However, it is very important to note that Airtable Sync does not automatically synchronize data on a reliable schedule, which could be a key stumbling block here.
Airtable states that Airtable Sync updates approximately every 5 minutes, but this is not true. The sync actually happens at some random point between 5 minutes and 20 minutes. But even worse, it will ONLY sync if there has been recent activity within the destination table, not the source table.
So this methodology will be unreliable if you’re looking for changes to be instantly reflected in the destination table, and it will also be unreliable if a record is created then deleted very quickly thereafter. In the latter case, you’ll likely miss knowing about that record altogether.
Yes, your example is very similar to my goals and the same logic should apply. Your suggestion was what I would also expect my script to evaluate. However, I haven’t found a way differentiate between the two tables because the ID of the deleted record is still returned using the selectRecordsAsync() method.
Did you perhaps use an alternative object method from selectRecordsAsync()?