Alright, let's cut through the marketing fluff and get to the meat of it. Everyone praises Salesforce's "clicks not code" mantra until you try to move actual data into their system using their own tools. The Data Import Wizard is a house of cards when you introduce anything beyond the most basic Account or Contact object.
My specific gripe? The tool fails silently or with spectacularly unhelpful errors when you have custom fields with specific data types, even when your CSV is perfectly formatted. We're talking about:
* **Lookup fields** that fail even when the external ID you're providing is correct and you've triple-checked the relationship name.
* **Multi-select picklists** that choke if you use the exact semicolon delimiter they specify.
* **Rich text areas** that cause the entire batch to hang because of an unescaped character.
The official documentation reads like a wish list, not a technical spec. "Just map the fields and go!" Sure. Here's the reality from our last migration attempt, where we tried to import a batch of 5000 custom Asset records with 12 custom fields.
```csv
"External_Id__c","Name","Custom_Lookup__r.External_Id__c","Multi_Picklist__c"
"AST-10001","Main Server","CUST-ABC","Value A;Value B"
```
The wizard accepts the file, validates, starts the job, and then... fails. The email you get says "An error occurred during import." The job status page might as well say "Figure it out yourself." After digging through the backend with a Salesforce support rep (a week-long ticket escalation), we found the issue was a trailing space in the picklist API name in the field mapping that the UI itself generated.
So my question isn't just "is anyone else having issues?"—we all are. My question is: **what's your actual, proven workaround when the official tool is fundamentally broken for non-vanilla use cases?** Are you scripting Apex Data Loader calls? Using third-party ETL tools to bypass the wizard entirely? Or have you resigned yourself to manually importing data in 200-record chunks after pre-massaging every field?
Because right now, the "best practice" of using the Import Wizard feels like being told to use a spoon to dig a trench.
The silent failures on rich text fields are often encoding related. Check your CSV for UTF-8 BOM. The wizard sometimes processes it as part of the first field value, corrupting the data.
For lookups, confirm the target object's external ID field is marked as "External ID" and is case-sensitive. The mapping `Custom_Lookup__r.External_Id__c` is correct, but the wizard's relationship cache can be stale. A metadata API call to describe the object can surface mismatches the UI doesn't show.
The BOM issue is real, but it's the canary in the coal mine. The core problem is they built a text-based wizard for a complex metadata API and didn't handle the edge cases. So every "solution" is just a workaround for their opaque error handling.
Your metadata API suggestion is correct, but it proves the point, doesn't it? The average admin trying to run an import shouldn't need to call the API just to see what their own UI *actually* understands about their org's schema.
And good luck with that "stale relationship cache." Refreshing it seems to require a combination of browser incantations and prayer.
Data skeptic, not a data cynic.