Troubleshooting Salesforce Data Loader errors?

Learn how to fix OAuth login issues, validation failures, duplicate rules, permissions, and ID-related errors step by step.

Interested in testing a pre-release of the Salesforce community’s first-ever Data Migration course? 
Sign up below to secure a spot. 

Here are the five most annoying Data Loader failures (the ones that repeatedly derail imports), plus practical ways to troubleshoot and unblock your upload fast.

“Oddly specific” validation error messages (records fail validation)

This type of error can be tricky because Data Loader doesn’t always indicate which specific field in the row caused the issue. Instead, you’ll see an error message like: “Clients must have a website.” At that point, you’re left trying to figure out which field is failing and why.

How to diagnose the real problem

Instead of guessing, treat the message like a clue. Read it and determine what it is not:

• It is typically not a duplicate rule error
• It is typically not an invalid field value error

The wording usually indicates a requirement needed to create a record that is missing from your source file.

Find the matching Salesforce validation rule

Go to the object’s Validation Rules and search for the rule whose error text matches what Data Loader reports.

Example: If you tried to create an Account with Status = Client but your file omitted Website, that record fails the validation rule and never gets created.

Three options to solve it

1. Deactivate the validation rule temporarily and reload:
   • Fastest path to get the load marked complete
   • But the rule will keep preventing updates until data satisfies the requirement
2. Fix the source data to include the required values:
   • Best long-term outcome because records are clean and validated
   • Be careful with “fake temporary values” like http://www.websitewebsite.com just to pass validation
3. Modify the validation rule to include bypass logic for admins:
   • Great for admins running loads
   • But if you are consulting on best practices, make sure the bypass does not turn into an “old process forcing new systems” problem
   • Otherwise, end users can get blocked all day by validation rules and feel like they have to fight the platform

Duplicate rule blocker (“Use one of these records?”)

When you insert or edit records that hit active duplicate rules, Salesforce can stop the import with the out-of-the-box message:

“Use one of these records.”

That message confirms your blocker is duplicate rules. One catch: duplicate rule alert text can be customized, so always double-check the rules if the text does not exactly match what you expect.

How to solve it

Ideally, you prevent duplicates in the first place. But during migrations, you sometimes have to load records that may be duplicates, knowing de-duping will happen later.

Fastest workaround options:

1. Temporarily deactivate the offending duplicate rules
   • Then reload
   • Do not forget to reactivate after the migration
2. Change the duplicate rule action from “block” to “allow”
   • Also remember to switch it back

“Insufficient access rights” errors (permissions, sharing, cross-reference)

This is the error that feels like Salesforce is playing hide-and-seek. The message often does not identify which field in the row is causing the issue.

Still, you can troubleshoot it systematically.

Start with a three-step method

1. Identify which specific error you got
2. Validate the ID values in your prepped file
3. If prep looks correct, investigate sharing/record access

Two flavors of insufficient access rights

Insufficient access rights to Object ID

This typically indicates a permissions problem on the object you are loading into.

• For example, inserting Opportunities may fail if the running user (or record owner) lacks object-level permissions for Opportunities
• It could also be field-level security missing for a field you are updating

Insufficient access rights on Cross-Reference ID

This points to a related record you are referencing that the running user or record owner cannot access.

• Example: inserting Opportunities and setting Contract ID without access to the Contract object can trigger this error

Speed Up Troubleshooting: Check the IDs you rely on

Because Data Loader inputs can contain multiple lookup relationships, field-by-field checks can become time-consuming. A high-yield place to start:

• Confirm record type IDs for the main object are valid
• If you are not using record type IDs, you can rule that out immediately
• If you are using them, verify:
  • Correct digit length (no malformed IDs)
  • No typos from prep work (including mistakes from VLOOKUPs)
  • Correct mapping from source to target columns

Any time Salesforce receives an ID it cannot find in the expected place, it can return an insufficient access error.

What about deleted or unshared records?

Two common hidden causes:

• Referenced record is deleted
  • Grab a referenced ID from the error file
  • Paste it into Salesforce in the URL format: https://yourInstance.my.salesforce.com/.../aftercom (use the pattern your org supports)
  • If it does not resolve, that ID is not valid anymore
• Referenced record exists, but is not shared with the record owner
  • Log in as the record owner
  • Try to access the referenced record
  • If they cannot see it, Data Loader cannot complete the load either

Salesforce can generate these errors for many reasons. The steps above cover the majority of real-world cases, but not every edge case.

“ID value of incorrect record type” (ID belongs to the wrong object or format)

This fifth error is similar in spirit to insufficient access rights. The key detail is that the ID Salesforce receives does not match what it expects for the target field.

What it means

You typically see it when an ID is:

• Assigned to the wrong field
• Belongs to the wrong object (wrong record type in the context)
• Malformed (wrong format, spacing issues)

How to troubleshoot it

Use the same mindset as the previous error: validate ID correctness first, then validate mapping.

• Ensure the ID is exactly 15 or 18 characters
• Ensure it has no white spaces
• Ensure the ID is the right ID for the target object and the right field you are loading

Yes, it is tedious. But it is also one of the fastest ways to learn how Salesforce wants your data model and file structure to line up so loads succeed.

Quick checklist before you hit “Finish” on a Salesforce Data Loader import

• OAuth/login: authentication host domain URL set correctly and Data Loader updated
• Validation rules: required fields included or validation logic bypassed intentionally
• Duplicate rules: know whether duplicates will be loaded and plan de-duping
• Insufficient access: check object/field permissions and sharing, especially for cross-reference IDs
• Incorrect record type IDs: verify ID length, spacing, and correct mapping

If you are stuck on another Data Loader error, the fastest path forward is usually the same: identify what Salesforce is actually blocking (permissions, validation, duplicates, or ID mapping) and then validate the IDs and rule logic that gate the load.