Engineering / Field guide
Spreadsheet-to-CRM integration: match records before syncing fields
A spreadsheet can look tidy and still create duplicate accounts. The hard part of a sync is deciding which real-world record each row represents.
2XD Studio · · 2 min read
Identify the stable key
Account names change punctuation, contacts change employers, and two branches can share a billing address. Prefer an authoritative external ID. Where one is missing, prepare candidate matches for review and write the approved CRM identifier back to a controlled mapping table.
Define ownership one field at a time
Sales may own the account contact while finance owns payment terms. A blank cell might mean unknown, unchanged, or deliberately cleared. Write down which meaning applies to each field. Test a blank update before enabling writes; otherwise an incomplete export can erase a valid CRM value.
Reconcile the first run
Start with a preview showing proposed creates, updates, unchanged rows, and ambiguous matches. Review a sample from each group. After a small live batch, compare IDs and counts against the preview. Keep a checkpoint and a way to replay just the failed rows without creating duplicates.
Run the blank-cell test
Take an account with a verified phone number and remove that value from the export. The preview should say whether the phone will be kept, cleared, or sent to review. Have the field owner confirm the decision before live sync. Then test a deliberate deletion using the agreed signal; preserving every blank can be as wrong as clearing every blank.
Reader questions
Can the sync run in both directions?
Yes, but each shared field needs an owner or conflict rule. Two unrestricted writers can reverse each other's changes indefinitely.
Should deleted spreadsheet rows delete CRM records?
Only if deletion is an explicit business event. A missing row in a partial export is not reliable evidence that an account should be removed.