When adding a sync table to our base, we have an option to either “delete the records” or “leave the records” in the destination table when the records are deleted from the source table.
See screenshot below for a screenshot of this option.
I find this Sync Setting problematic for 3 reasons:
It’s not truly a “sync” if the records are mismatched between 2 tables.
We have absolutely no way to distinguish (in our destination table) whether or not a record was deleted in the source table. Airtable gives us absolutely no way to tell if a record still exists, or if it’s just a “phantom ghost record” that once existed a long time ago.
This is yet another security hole in Airtable. If I delete a record from a base, it’s probably because I don’t want anyone to see that record anymore. Yet anybody who has formerly setup a sync to my table can now see previously-deleted records. From a security standpoint, this is greatly flabbergasting to me.
Can someone please help explain the above 3 concerns to me?
It’s not truly a “sync” if the records are mismatched between 2 tables.
One of the primary reasons we have this option is that synced records can be enriched with additional columns. Consider a synced table where you added in a notes column and spent a significant amount of time iterating on your notes. If the record is deleted in the source, the data you entered in would be irrecoverably lost. Also consider the case where users link to records in the synced table. Deleting the record could easily cause lookups/rollups/filters/automations etc to break/behave in odd ways. Our user research indicated that this was a significant concern.
We have absolutely no way to distinguish (in our destination table) whether or not a record was deleted in the source table. Airtable gives us absolutely no way to tell if a record still exists, or if it’s just a “phantom ghost record” that once existed a long time ago.
We’re still working through how to expose this better, but for now, it’s possible to use the ‘Open Source Record’ button action as a workaround. If the value of the button field is empty, the record is hidden or deleted in the source.
This is yet another security hole in Airtable. If I delete a record from a base, it’s probably because I don’t want anyone to see that record anymore. Yet anybody who has formerly setup a sync to my table can now see previously-deleted records. From a security standpoint, this is greatly flabbergasting to me.
We understand your concern and are still thinking through additional security features. However, consider the possibility that the sync is set up to be manual (i.e. it does not update automatically). In that scenario, deleting the records from the source has no impact until the next time the user chooses to manually sync (this is also possible if the sync breaks for any reason). Even for the automatic sync case where the ‘Delete records in this table’ option is on, it’s possible that a backup occurs after you delete the records on source, but before the records are deleted on target. When you recover that backup you could see the deleted rows. It is extremely difficult to guarantee that deletions are propagated to the source, so we would recommend configuring the source view to be extremely selective if you’re concerned about this (e.g. consider filtering on a ‘send to other table’ checkbox field).
Thanks so much for your replies to my concerns! :slightly_smiling_face:
Ahhhh, I see what you’re saying here. That actually makes a lot of sense. You’re not JUST syncing records between different bases, but you’re allowing people to enrich the synced record by adding their own fields in the CURRENT table that are associated with each source record. Yes, that makes sense. If a record got deleted from the destination table after being deleted from the source table, it could potentially be catastrophic to the user of the current table.
Ooh, that’s a nice little workaround for now! Thanks for that hot tip! :grinning_face_with_big_eyes:
I really like how it “dims” the name of the button, if the source record doesn’t exist.
Here’s 2 other ideas for this:
Perhaps you could create a formula function that can test for the presence of a synced record? Something like SYNCED_RECORD_EXISTS() that returns “true” or “false”. Then, we could use it in our own formulas to display what we want.
Perhaps there could be conditional coloring applied to the record if it no longer exists (in addition to other colors that are applied).
Very interesting. Thanks for the extra information on this.
Overall, really amazing job with this new sync feature!! It’s super-cool, extremely easy to configure, and extremely intuitive!! Great job!! :grinning_face_with_big_eyes: :raised_hands: :clap: :thumbs_up: :star2:
I don’t think It is a security issue. There are cases where you would need this feature and it something that I needed desperately. For example, a synced record in a destination table holds old information that is necessary for reviewing past data even if it is no longer active/present in the source view.
