System Integration: What Should Happen When a Record Disappears?
Start with the short answer ↓
A record missing from an API response is not proof of deletion. Check pagination, filters, permissions and change-feed semantics before an integration archives records, closes work or propagates a destructive action.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Do not turn absence into a deletion command
An integration reads the CRM's active-customer view. One customer no longer appears, but their service job is still open in the operations system. Should the integration cancel that job? Not from this response alone. The customer might have been archived, excluded by a filter or become invisible to the integration account. This is an illustrative scoping example, not a customer incident or a delivered-system claim.
Agree what each source response actually represents before deciding what to remove downstream. A partial list, an incremental change feed and a complete authorized snapshot answer different questions. Even a complete snapshot only establishes absence within its documented scope; it does not automatically authorize deleting related business work.
First establish whether the read is complete
Record the endpoint, filters, account permissions, time of the read and whether every required page was successfully processed. If a page failed or the filter changed, do not compare the result with yesterday's full list as though the populations were identical. A successful HTTP response alone does not establish that reconciliation is complete.
Microsoft Graph's delta-query documentation explicitly notes that a response can contain an empty page and still provide a next-page link. Delta queries also describe changes rather than a fresh inventory of every record. These are concrete API examples, not universal rules for every provider. Read the contract for the endpoint you will actually use.
Use a decision matrix before changing downstream records
Our proposed worksheet separates the observed signal from the business action. The implementation team must fill in the provider-specific evidence and the responsible owner. A hold on destructive propagation is not permission to keep exposing information after access has been revoked.
| Observed signal | What it establishes | Proposed response |
|---|---|---|
| Missing from one filtered or incomplete list | Only that the record was not returned in that read. | Check scope and remaining pages; hold destructive reconciliation. |
| No event for the record in an incremental response | No reported change under that feed's rules, not absence from the source. | Retain the permitted current state; continue from the provider's documented checkpoint. |
| Removal or access-loss signal | The meaning depends on the API; it may not prove deletion. | Apply access restrictions promptly and classify the signal before propagating deletion. |
| Confirmed deletion from the authoritative source | A source-side deletion, not automatic permission to cancel linked work. | Apply the approved archive/delete policy, dependency checks and required review. |
Treat access loss differently from ordinary missing data
Google Drive's Change resource documents that its removed field can indicate deletion or loss of access. An integration that treats that flag as an unambiguous deletion may make the wrong downstream decision. Equally, assuming every removal is temporary can leave a synchronized copy visible to someone who should no longer see it.
Specify how the destination restricts access to affected synchronized content while an authorized owner investigates. Keep only the minimal evidence permitted by the organization's policy, such as a record reference, classification and checkpoint. Do not copy the restricted content into an unrestricted exception log. The right archive or deletion outcome depends on the actual permissions, relationships and agreed retention rules.
Resolve the open service job as a separate decision
Return to the example: the customer vanished from the active view because staff archived the CRM profile. The proposed rule could stop new work for that customer while preserving an already authorized service job for review by its owner. It should not silently cancel the appointment, issue a refund or erase the job history. This is one possible policy to discuss, not a recommended default for every business.
Give the exception a named owner and a next action: verify the source status, check remaining obligations and choose the permitted destination state. If the record reappears, match its stable source identifier and review the current status before reactivating anything. Avoid creating a second customer or replaying an old cancellation merely because another sync ran.
Separate a retry from permission to repeat a business action
Test disappearance before the first live reconciliation
Use an isolated test environment with real sending and irreversible writes disabled. Include six cases: a truncated paginated response; a changed active-only filter; revoked access; an incremental response with no change; a confirmed authorized source deletion; and a record that later reappears. For each case, write the expected destination visibility, linked-work status, reviewer and recovery step before running the test.
Acceptance means more than preventing deletion. Confirm that restricted content stops being exposed, ordinary updates still work and a completed review does not cause duplicate actions on the next run. Keep the provider contract, test outcome and operating owner with the integration scope. These references explain API behavior; they do not establish that AgenticShip already provides a connector for either platform.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.