Study first
Review the ideas behind the questions
These notes help you review a CRM import before records change. Focus on the object type, matching key, association plan, overwrite behavior, and the evidence needed before rerunning a failed file.
Map the file to the CRM job
Import Checks start by deciding what the file is allowed to do and which CRM object each column should update.
- A CRM import can create records, update existing records, and define relationships between records when the file is mapped correctly.
- For create-and-update imports, the file needs required properties for new records and a unique identifier for existing records.
- A column should be left out of the import when it should not update a CRM property.
In Practice
Decide create, update, or both
Pick the import mode before mapping fields. A migration file that mixes new and existing records needs both required fields and matching identifiers.
Check skipped columns deliberately
Do not let unmapped columns become accidental data loss. Confirm whether each skipped column is intentionally excluded or needs a matching CRM property.
Common mistakes
Treating every spreadsheet column as safe to import.
Map only the columns that support the import goal, and exclude columns that should not change CRM properties.
Q&A
What should be decided before mapping import fields?
Decide whether the file should create records, update existing records, or do both, because that choice changes the required matching data.
Why inspect columns that will not be imported?
Skipped columns may be intentional, but they should be reviewed so needed migration data is not left behind by mistake.
Preserve identity and associations
Association imports need a reliable way to connect rows without creating duplicate records or linking the wrong objects.
- Files that update existing records or avoid duplicates need a unique identifier for each object.
- When importing two objects in separate files, the files need a shared column that connects the records.
- Same-object association imports have extra requirements, including that at least one record in the pair already exists.
In Practice
Use the right shared key
For two-file association imports, the shared column should identify the relationship clearly. A vague shared value can connect records incorrectly.
Do not use association import as cleanup guesswork
Association mapping should be based on identifiers that are already trustworthy enough for the record pair being imported.
Common mistakes
Using a common column that exists in both files but does not identify the relationship.
Use a shared column that clearly connects the intended records, then confirm which object owns that shared key.
Q&A
What is the first risk in a two-file association import?
The two files may not share a trustworthy common column, so the import cannot reliably connect the intended records.
Why are unique identifiers more than a cleanup detail?
They determine whether the import updates or associates existing records instead of creating avoidable duplicates.
Review errors before rerunning
A failed import is a signal to inspect the file and mapping, not a reason to keep uploading the same data.
- Import files need a supported file type, one sheet, and a header row that maps to CRM properties.
- Prevent overwrite settings can update blank new values without replacing existing values that already have history.
- Import error review should fix the file issue before the same rows are uploaded again.
In Practice
Protect existing values on enrichment
When enrichment data is incomplete, use overwrite controls for fields where blank or weaker imported values should not replace known CRM values.
Treat errors as file feedback
A failed row usually points to a specific file, value, or mapping problem. Fix the cause before rerunning the import.
Common mistakes
Rerunning a failed import without changing the file.
Review the error, fix the file or mapping cause, and rerun only after the import setup is corrected.
Q&A
When should overwrite protection be considered?
Use it when the import should fill missing values but should not replace existing CRM values that already have history.
What makes an import file structurally ready?
It uses a supported spreadsheet or csv file type, has one sheet, and includes headers that map to CRM properties.