Currently in the List Records API, records that are deleted from the UI do not appear in the response – and there is no audit column marking a record as deleted. We would like to take an incremental ingestion strategy for table records, but the inability to track deletions forces us to pull full data loads. Our ingestion component is performing fine currently, but we have concerns about scaling and cost management. Are there any plans to enhance the List Records API to detect deletions?
Hi @alex.kuhn - We don’t have any plans to add this at the moment as it’s not necessarily as quick an improvement as it might seem. I wonder if there are any other options in the short term to reduce the amount of data you have to pull for ingestion? Are there any more specifics you can share here about the logic that drives your current process?
If not we could also discuss via email or another channel.
Our team “solves” this with an inelegant work around - whenever an app deletes a record we ask the app developer to instead to append -DELETE (eg to the ID or to a serial number), then we receive the record but can easily exclude it from apps and analysis.
2 Likes
An easy solution here would be to have an instance or workspace level setting that just disables the ability for anyone to delete records. App builders would be forced to develop with table based definitions of data archiving or deleting.