Detect Partial CRM Imports Behind Success Messages
Reconcile source rows, complete records, partial property failures and rejections before retrying a CRM import or releasing records for downstream use.
10/23/20263 min read
An import dashboard reports success, yet the account owner sees empty region fields and missing contacts. The dashboard may mean the job finished, not that every intended value was written. Some tools separate rejected records from rejected properties; some report successful updates even when the supplied value matched the existing value.
Before rerunning anything, establish what happened at the record and field levels. A second full import can duplicate accepted rows or overwrite newer corrections. The essential artifact is a reconciliation worksheet that connects each source row to an observed outcome.
Define success at three levels
Job success means the process reached a completed state. Record success means the intended record was created or matched. Property success means the specific approved values arrived correctly. Associations and workflow side effects may need their own checks. Do not collapse these outcomes into one green cell.
HubSpot's error documentation distinguishes skipped rows from skipped property values. That distinction matters because a row can create a record while one of its fields fails. Use the actual error report and destination evidence to classify outcomes; do not infer them from a generic banner.
Before running a pilot, write the expected source-row count, unique source keys, intended creates, intended matches, and field-level invariants. Include exclusions deliberately removed before import, so they are not later mistaken for missing records.
Fill in a source-to-result worksheet
The following synthetic case uses twelve source rows. It is an arithmetic demonstration, not a reported customer outcome.
Input received: twelve rows, each with a stable source-row key.
Pre-import exclusions: two rows held because mandatory identifiers were missing.
Attempted: ten rows.
Fully applied: seven rows, comprising four new records and three updates.
Partially applied: two rows created records but failed their region property.
Rejected without the intended record operation: one row with an invalid required value.
The attempt equation is ten equals seven fully applied plus two partially applied plus one rejected. The pre-import equation is twelve equals ten attempted plus two excluded. Neither equation alone verifies that the seven apparently complete rows contain correct values.
For each attempted row, store the source key, destination ID, intended action, observed action, affected properties, error reference, and next decision. Avoid using email addresses as worksheet keys when a nonpersonal internal reference serves the purpose.
Test the evidence against the destination
Export only the necessary destination fields and match them to the worksheet. Check that the six created records in the fictional case really exist: four complete creates plus two partial creates. Then inspect the three successful updates and the one rejected operation separately. If a rejected row matched an existing record, confirm whether any properties changed before the failure.
A record count can be unchanged after a legitimate update. Likewise, two source rows might target one destination record. Record intended identity mappings before deciding that a count discrepancy proves a failure. Unexpected many-to-one mappings still require review, even if the tool considers them valid.
Compare critical fields individually. A missing optional note might be tolerable under a documented exception; a missing suppression flag or wrong account association should block release of affected outreach. Define those severity decisions before the operator is under pressure to finish.
Retry only the unresolved operation
In the illustrative case, the two partial records already have destination IDs. Correct their region values through a tightly scoped update rather than replaying their creation rows. Fix and retry the wholly rejected row only after confirming what, if anything, the first attempt wrote. Keep the two pre-import exclusions outside the retry file until their original problem is resolved.
Give the retry a new run identifier linked to the first attempt. Reconcile it separately and then update the combined outcome. Never erase the initial error report simply because the later attempt succeeded; retain the minimal evidence needed to explain the sequence under the applicable retention plan.
Finish with a release statement that distinguishes complete, partially complete, rejected, and excluded work. State whether downstream use is permitted for each group. A trustworthy report may say “nine records resolved; three source rows remain held” rather than claiming the whole list succeeded. The point is to make unfinished work visible and prevent an attractive status label from replacing evidence.
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.