A clean research file can still create a messy CRM when company and contact fields are mixed, identifiers are missing, picklists disagree, or automatic deduplication merges the wrong records. The import preflight should protect the business identity, location, public-contact route, source evidence, review date, campaign context, and outreach state. This lesson is CRM-agnostic: use the destination system’s current import instructions and test environment, then adapt the map to its actual objects and limits.
VISUAL LESSON
What you will learn
- 01Define source and destination objects and fields.
- 02Choose identifiers, normalization, and merge rules.
- 03Test and reconcile a controlled import.

ILLUSTRATIVE WORKED EXAMPLE
Reconcile an illustrative 500-row import test
PRACTICAL INTERFACE MAP
Map, test, and reconcile the CRM handoff
Inventory raw fields, destination objects, required types, picklists, ownership, permissions, and source evidence.
Define company, location, and contact identifiers plus exact create, update, duplicate, blank, and conflict behavior.
Use representative rows, capture the result, inspect relationships and automation, then reconcile accepted, rejected, and merged records.
STEP-BY-STEP LESSON
Reviewed file → explicit field map → identity gate → reconciled CRM
THE LEAD ATLAS METHOD
Lead Atlas Data can prepare a custom business-contact list around the customer’s campaign, market, locations, and business categories; an explicit CRM field map then preserves the research context when that list enters the working system.See how custom list research works ↗Inventory the source and destination
List every source column, definition, example, data type, null meaning, source, review date, owner, sensitivity, and destination use. Then list the CRM’s current objects, required fields, property types, picklists, relationships, permissions, limits, automations, workflows, and import options.
Decide whether a row represents an organization, location, contact route, person, campaign membership, or a combination that must be split. A headquarters company, branch office, general inbox, and named contact should not be collapsed into one object merely because they appear in one spreadsheet row.
Define identities and relationships
Choose stable external keys for organization, location, and contact where the CRM supports them. Document how domains, addresses, phones, emails, parent-child relationships, franchises, and same-name businesses contribute to a match, and which contradictions require manual review.
Specify create, update, skip, and conflict behavior. Never use a blank incoming value to erase a reviewed CRM field without an explicit rule, and do not merge two businesses solely because a normalized name or central phone matches.
Build the field map
For each source column, record destination object, property, type, transformation, allowed values, maximum length, blank behavior, update policy, owner, and rejected-value route. Preserve raw business name, raw contact route, source URL, review date, campaign brief, and a research-record key even when normalized fields are added.
Normalize phone, domain, email, country, region, category, and dates consistently, but retain original values for audit. Map consent, subscription, legal-basis, do-not-contact, and suppression fields only according to the organization’s rules; a public address is not an automatic opt-in.
Test a representative sample
Create a labeled test file containing new records, updates, blanks, multi-location businesses, duplicate domains, shared phones, general inboxes, international characters, invalid picklists, long values, and known conflicts. Use a sandbox or reversible low-risk process where available.
After import, inspect created and updated objects, relationships, owners, campaign membership, source fields, rejected rows, duplicate suggestions, workflows, notifications, assignments, and integrations. Check that automation did not send live outreach or overwrite evidence during the test.
Reconcile and release
Compare source rows with created, updated, skipped, rejected, and merged destination records. Resolve every exception, approve the production file and import settings, schedule the run, preserve the file checksum and operator, and monitor downstream automation.
Deliverable: source dictionary, destination schema, object model, external-key rules, relationship and merge policy, field map, transformations, representative test file, import capture, exception log, reconciliation totals, automation review, approved production manifest, rollback plan, and post-import audit.
Turn this lesson into a research brief.
Apply “CRM Import Preflight: Map a B2B Contact List Without Losing Evidence” to one campaign before requesting or using a list.
- 01Market boundary
Name the locations and business categories this decision applies to.
- 02Fit evidence
Write the public signals that would make a business relevant enough to review.
- 03Exclusions
List the business types, markets, and records that should not enter the campaign.
- 04Outreach use
State who will review the list, personalize the message, and record outcomes.
THE TAKEAWAY
Map objects and fields before import, keep stable identifiers and raw evidence, test a reversible sample, review merge behavior, and reconcile the destination row by row before the file becomes operational.OFFICIAL REFERENCES