Salesforce data import errors need a row-level investigation, not another attempt with the same entire spreadsheet. Some records may already have imported successfully. Others may be valid but invisible in the current list view. Repeating the full file can create a second problem while leaving the original cause unresolved.
Quick answer
Start by preserving the original file, locating the import result, and separating successful records from failed rows. Diagnose one representative error, repair a small test batch, and verify the destination records before retrying the remaining failures.
Key takeaways
- Preserve the original import file and separate successful records from failed rows.
- Repair one representative error family in a small batch before retrying.
- Respect validation and permissions; reconcile destination results rather than replaying the whole file.
Documentation reviewed October 9, 2026. This guide focuses on Data Import Wizard troubleshooting, not a complete migration or a promise that every object supports the same import method.
Freeze the incident evidence
Keep an untouched copy of the file that produced the error. Record the import time, importing user, target object, selected add or update behavior, and any matching choices. If several people are importing simultaneously, identify which job belongs to your file before drawing conclusions.
Create a separate working copy for repairs. Maintain an internal row reference that lets you relate a corrected row to the original source record. Do not import that reference into an arbitrary Salesforce field without checking the mapping. Its initial purpose is to make your troubleshooting reproducible.
Restrict access to the files because customer and employee data may be present. Remove unnecessary columns from support examples. A useful diagnostic sample preserves the relevant structure and invalid value without exposing the entire customer list or authentication information.
Our CRM migration checklist is useful when this import is part of a larger move. For the immediate incident, avoid changing the migration plan until you understand the failed job and the exact rows affected.
Prove whether records failed or are merely hard to find
Salesforce’s missing-records troubleshooting guidance recommends reviewing the import job and its processed and failed counts. A completion email does not establish that every row succeeded. It also distinguishes record visibility in list views from the result of the import itself.
Choose one expected record and search using an approved identifying field. Check the relevant object and an appropriate list view rather than relying only on Recently Viewed. If another authorized administrator can see the record but you cannot, investigate visibility with the administrator. Do not broaden permissions merely to make a troubleshooting screen look complete.
Build three groups: confirmed successful rows, confirmed failed rows, and rows whose outcome remains uncertain. Do not put uncertainty into the failed group for convenience. Check job evidence and destination records until a replay decision is justified, or escalate the unresolved case.
Record counts carefully. If the source file contains 200 intended records and the job confirms 180 successful rows, a repaired file should not automatically contain all 200 again. Your next step depends on what happened to the other 20, not on how easy it is to reuse the original file.
Group failures by error family
Read the actual row-level error rather than diagnosing from a generic completion message. Group similar failures so you can repair a representative case and test the transformation. Preserve distinctions between a missing required field, an invalid format, an unavailable mapping, and a rule that rejects otherwise well-formed data.
| Error family | Investigation | Safe repair principle |
|---|---|---|
| Invalid field or format | Check destination field definition | Transform the value, not the schema blindly |
| Required value missing | Locate approved source information | Do not invent customer data |
| Parent relationship missing | Verify parent and supported mapping | Use an existing valid relationship |
| Rule or picklist rejection | Review accepted values with administrator | Preserve governance |
| Outcome uncertain | Check job and destination evidence | Do not replay as if nothing happened |
The categories guide investigation; they are not universal Salesforce error codes. Copy the exact code and message into your restricted incident record. If two errors look similar but reference different fields, do not assume the same transformation repairs both.
Repair field-format errors at the source
Salesforce’s INVALID_FIELD guidance identifies unsupported value formatting and references to nonexistent field names as possible causes. Its date example contrasts an unsupported dotted format with supported alternatives. Confirm the actual field’s data type and applicable import format before modifying the failed rows.
Dates deserve special attention in teams spanning the US, Canada, the UK, and Australia. A value such as 03/04 can be interpreted differently by different people. Determine the intended date from the source and use a documented unambiguous representation appropriate to the importer. Do not let a spreadsheet’s display format make that decision silently.
Preserve identifiers as identifiers. A spreadsheet may change their appearance through automatic formatting, particularly where leading zeros or long numeric-looking strings are involved. Inspect the saved CSV, not just the visible spreadsheet cells, before approving the repaired file.
Compare the exported header and mapping with the destination field definition. A friendly spreadsheet label is not proof that a matching destination field exists. Ask the administrator to confirm the supported mapping rather than creating a new field solely to silence one import error.
Resolve missing required and relationship information
For a missing required value, identify its approved source. If the information is genuinely unknown, quarantine the row and obtain a business decision about how it should be handled. Placeholder contact details or guessed classification values create misleading records even if they satisfy a technical requirement.
Salesforce’s master-detail import guidance explains that required parent relationship information must be supplied for affected records; a mapped column with blank values is not enough. Verify the intended parent record and the supported relationship mapping before retrying those rows.
Do not use a similar-looking account name as definitive evidence of the parent. Two companies can share a name, and one company may have several accounts for legitimate reasons. Use the organization’s approved matching rules and ask the data owner to resolve ambiguity.
If the parent has not been created, document that dependency rather than repeatedly importing the child. The recovery plan might require a reviewed parent import first, followed by verification and then the child rows. Keep each job’s results separate so partial success remains visible.
Respect validation and access controls
Salesforce’s generic import-failure guidance discusses causes including missing required fields, invalid picklist values, blank rows, and validation-related rejection. Use the exact job evidence to distinguish them. A generic failure does not justify disabling every rule.
When a rule rejects the data, ask what business constraint it protects. The file may need transformation, or an administrator may need to review whether the rule fits an approved exceptional process. Any exception should be scoped, documented, and authorized. Do not trade a green import result for ungoverned records.
If a field is unavailable in the mapping, inspect the supported object, importer, and account permissions with the administrator. Salesforce documents that lookup-field mapping availability can depend on page layouts and field-level security. Diagnose the constraint before requesting broader access.
Our CRM requirements guide helps document intended behavior. Keep an import repair aligned with those requirements rather than changing the data model to accommodate an unreviewed source file.
Build a small, representative repaired batch
Select a few failed rows that cover the error families you intend to repair. Include an edge case such as a non-US date or an ambiguous relationship where relevant. The purpose is to test the repair logic, not to achieve a flattering success rate by choosing only easy rows.
Decide how those rows should behave: create a new record, update a known existing record, or remain excluded pending review. Verify the importer’s supported matching options and target identifiers for that decision. Do not assume that rerunning a source row automatically updates its previous record.
Use an approved test environment when available, keeping the production object’s configuration differences in mind. If a production test is necessary, obtain approval for the small scope and document any follow-up work. Avoid triggering unwanted customer contact or downstream automation through an unreviewed trial.
After the batch completes, inspect destination values and relationships, not only the job status. Confirm that dates retain their intended meaning, identifiers are intact, and existing records were not duplicated or overwritten unexpectedly. A successful technical import is only the first acceptance check.
A fictional case: mixed date errors and partial success
Suppose a consultancy imports 200 contacts. The job confirms 180 successes and 20 failures involving a date field. The team considers uploading the whole file again after changing the date column. That would ignore the 180 records whose import has already succeeded.
The operator preserves the original job results, isolates the 20 failed rows, and confirms their intended dates from the source. A small representative set is reformatted using the documented field format. The administrator verifies those records and checks that no unintended duplicate contacts were created.
Only after that test does the operator prepare the remaining confirmed failures. Any row whose previous outcome cannot be established stays outside the automatic retry. The incident record connects each repaired row to its original error and final destination record.
This is an illustrative workflow, not an assertion that date formatting explains most import incidents. The same method works for other causes: establish outcomes first, repair a demonstrated error, and verify a small batch before expanding.
Close the incident with reconciled results
Reconcile the intended source records with successful destination records, intentionally excluded rows, and unresolved cases. Give every unresolved case an owner. Do not report the import as complete while a spreadsheet of failures remains unassigned.
Save the approved transformation rules, field mapping, importing account, and final job references. Remove unnecessary working copies according to your data-handling policy. A later import should use the reviewed process rather than rediscovering the same requirements from an old email attachment.
Our CRM implementation guide supports that operational handoff. If an ongoing process needs a different import tool, evaluate it separately with the administrator; this incident is not authorization to bypass object restrictions or install new software.
Common questions
Should I retry only the failed rows?
Usually that is the safer starting scope, but first confirm they truly failed and determine the correct create or update behavior. Uncertain outcomes need verification before replay.
Can I rename an Excel file to CSV?
No. Use the application’s actual CSV export or save process, then inspect the resulting file and mapping. A changed extension does not establish a valid import file.
What should I send to support?
Provide the job reference, exact error, target object, importing context, and a sanitized representative row. Do not send credentials or an unrestricted customer database.
The next import should be smaller and better explained
For Salesforce data import errors, preserve the evidence, separate partial success from failure, and repair a small representative batch. Verify destination records before retrying the remainder. That approach protects both data quality and the records that already imported correctly.
Join the conversation
Share a useful perspective, question, or first-hand experience with other Daily Jade readers.