Error Handling
Part of Workflow data synchronisation
Handling deleted records during synchronisation
Set delete and restore rules for paired records, check actual deletion signals and prevent an unwanted record from reappearing.
Set a separate rule for deletion in each system: remove the paired record, archive it, leave it in place or ask an owner to decide.
A record missing from a response has not necessarily been deleted. It may be filtered out, inaccessible or absent from an incomplete scan.
Decide whose deletion counts
For each record type, name who may delete it and whether the other application still needs it. A sales contact removed from an operational list might remain useful as a historical reference in a service system. In that case, an inactive or archived state may fit better than removing the service record.
Record what happens when system A deletes a record and when system B does. Include whether restoration is permitted and whether the former pair of IDs should reconnect. If one system owns the record lifecycle, deletion of its receiving-side copy may call for investigation rather than an upstream delete.
Observation / First decision
- Documented delete signal for a paired ID
- Apply the agreed delete or archive rule
- Record absent from a partial or filtered list
- Complete the scan and check access before changing it
- Paired record missing on only one side
- Check whether deletion or recreation was authorised
- Documented restore or undelete signal
- Apply the agreed reconnection or recreation rule
Deletion Handling Across Platforms
- Google Calendar Sync
- Includes deleted entries; client must remove from store
- Microsoft Graph Delta Query
- Discovers deleted entities via @odata.nextLink and @odata.deltaLink
- HubSpot Data Sync
- Monitors record state changes; can recover dropped API calls
- Salesforce CDC
- Provides event fields for deletion tracking; supports tombstoning
Read the source’s deletion contract
Google Calendar incremental sync includes deleted entries so a client can remove them from its store. Microsoft Graph delta query lets applications discover deleted entities and uses @odata.nextLink and @odata.deltaLink to retrieve pages and track later changes. Check the selected resource’s deletion contract and define restoration behaviour rather than assuming a universal deletion format.
A later full inventory can miss the history behind an absence. If the destination still has an old copy, a refresh that creates every unmatched source record from the destination could resurrect something deliberately removed. Retain a deletion decision or tombstone long enough for the integration’s actual recovery window, with retention set by the business lifecycle rather than an arbitrary number.
Control recreation
HubSpot’s data sync description says its index compares records, monitors their state as record properties change, and can recover dropped or errored API calls. Define and test what happens to paired records when one is deleted for the connected app before enabling automatic recreation.
A practical check includes deletion on each side, a record excluded by a filter, restoration and a missed deletion followed by refresh. Compare the expected paired IDs and visibility with the actual records. Leave an ambiguous deletion assigned to an owner rather than letting a refresh guess which application was right.
![How to choose the right idempotency key for an event: Keep the same idempotency key for retries of one action; use a new key for a new action.; Write: one [effect] for each [identity], e.g. one standard invoice per approved order.; Check stability, uniqueness, scope and lifetime; include tenant ID for tenant-scoped IDs. Choosing an idempotency key for an event](/covers/choosing-an-idempotency-key-for-an-event-640.webp?v=39704930)