Handle Deleted Records in Repeat CRM Imports
Design minimal deletion markers and precedence rules that prevent record resurrection while distinguishing true deletion from missing export rows.
10/23/20263 min read
A record removed from the CRM reappears during next week's import. The source export still contains it, and the integration treats a missing destination record as something to create. This resurrection can undo a cleanup decision, restore obsolete entities, or interfere with a privacy-related removal process.
Define how deletions propagate before scheduling repeat imports. A missing row is not always a deletion instruction: it might reflect a filter, an export failure, or a partial source snapshot. The workflow needs a deliberate distinction between absence, retirement, deletion, and temporary unavailability.
Identify the authority for a deletion
Record which system owns the decision and what the decision means. A source may retire a company listing while your organization still needs a historical account record. A privacy request may require a different process from ordinary commercial cleanup. Route sensitive cases to the responsible privacy owner rather than treating every deletion as a synchronization convenience.
HubSpot's deduplication guidance notes that blank Record IDs can create new records during imports. That is one reason an old source row must not simply lose its destination ID and return as a new candidate. Check the actual behavior of your repeat-import route.
Use the least information needed to prevent unintended recreation, subject to approved retention. A deletion marker should not become a hidden replacement database containing all the information that was supposed to be removed.
Design a tombstone record carefully
A tombstone is a minimal record of a deletion or retirement decision used to control later processing. Its appropriate content depends on the purpose and applicable requirements. Consider a stable internal key, decision type, effective date, scope, authority reference, and review condition. Avoid unnecessary descriptive or personal fields.
The matching design must still work after the active record is gone. If the source can recycle identifiers, a key alone may wrongly block a different future entity. Document namespace, object type, and version or other justified disambiguation. Do not solve this by keeping every deleted record forever.
Work a fictional repeat-import test
A synthetic account R71 was retired after a verified duplicate resolution. R72 is temporarily absent from a partial export. R73 was deleted under a separately reviewed privacy process. The next import contains R71 and R73 again but not R72.
R71: match the approved retirement marker; prevent automatic recreation and preserve the surviving-account mapping where justified.
R72: absence from this partial export does not authorize deletion; preserve its current state pending source completeness checks.
R73: stop and route to the privacy owner's approved handling rule; do not recreate it from the historical file.
R74: a genuinely new synthetic key; process under ordinary creation controls.
The expected output distinguishes four decisions. A single “not found” branch would handle them incorrectly.
Put precedence ahead of creation
Check applicable deletion and suppression controls before deciding to create a record. Then evaluate source identity, source version, and intended action. If the import cannot enforce those checks, stage candidates in a review area rather than allowing direct creation.
Test an old full export, a new partial export, and a corrected source file. Confirm that the same retired key remains held across reruns, that unrelated new records are not blocked, and that missing rows do not trigger mass deletion. Inspect downstream tasks as well as database rows.
Do not erase a tombstone merely because a newer file contains the record. Require the documented reinstatement authority and evidence appropriate to the original decision. A sales owner cannot casually reverse a privacy instruction by calling the account commercially interesting again.
The completed artifact should name the authoritative system, deletion types, matching fields, precedence rules, retention owner, and reinstatement route. Record exceptions with accountable owners. If the source cannot distinguish a complete snapshot from a partial one, hold any absence-driven deletion logic. Repeat imports should respect deliberate lifecycle decisions rather than treating every old row as an invitation to start over.
If you are also choosing research access, ask about Leads Automation’s independent Sales Navigator offer at US$15/month on WhatsApp. Confirm the available plan, eligibility and terms before ordering; this is not LinkedIn’s official price or an assurance that any particular integration is included.