A client of mine just restored some records from their base trash, and we stumbled upon some unexpected & troubling behaviors. I’m guessing that this is how Airtable wants all of this to function, but there are some problems & inconsistencies here:
- If you delete a record from your base, and then you restore that record from the base trash, the record reappears in your base with the original creation time and the original Record ID (as I would expect).
- However, instead of reappearing with the original “last modified time” (as I would also expect), it updates the “last modified time” to the time of the restoration. That’s a weird choice for Airtable to make, because the record wasn’t actually modified. However, to remain consistent with that behavior, Airtable should show something in the revision history for why its last modified time was updated to right now. But it shows no new activity in the revision history.
- Because the last modified time was updated to right now, if you have any automations that are set to trigger based on an updated record, all of those automations will now trigger.
- In addition to this record being considered an “updated record” by Airtable’s automations also considered this record to be a “new record” — even though its original creation time was not changed. So if you have any automations that are set to trigger based on a newly-created record, those automations will ALSO trigger. (This is similar to how synced records will be considered “new records” if they suddenly appear in the table.)
I would say that I wasn’t expecting any of this behavior (and it definitely isn’t desired behavior at all), but it’s problematic that:
- Restored records will trigger automations for BOTH “new records” AND “updated records”, yet
- There is no consistency in how Airtable handles the creation time & the last modified time.