Save as CSV in UTF-8, add an external ID column, load parents before children, use upsert rather than insert, and dry run into a sandbox first. Those five decisions prevent almost every problem people have with spreadsheet loads, including the expensive one: a rerun that creates a second copy of everything.
The method
- Decide the target object and record type, and pull the field list. Not the field labels: the API names and the required flags.
- Add an external ID column to the spreadsheet, populated with a stable value from the source system. This is the single most valuable thing you can do.
- Normalize formats in the spreadsheet: dates in the format the loading user's locale expects, numbers without thousands separators, picklist values matching the target exactly, booleans as true or false.
- Load parents first, keep the returned ID map, then load children referencing either the parent ID or the parent's external ID.
- Dry run the full file into a sandbox. Not a sample. Sample loads pass and full loads fail.
- Load with upsert on the external ID, then verify a random sample field by field rather than checking the row count.
The traps that fail quietly
- No external ID. Every rerun inserts again. This is how orgs end up with three copies of the same account.
- Locale mismatch. A file written as day-month-year loaded by a month-day-year user produces plausible, wrong dates that nobody notices for months.
- Trailing whitespace in picklist values. Rejected, or worse, accepted into a new value.
- Active automations. Your Flows fire once per row. Decide that deliberately rather than discovering it.
- Required fields on the target record type that the source never captured. Decide the default before the load, not during it.
When the spreadsheet is really a feed
Ask where the file came from. If it was exported from another system, it will be exported again. A custodian file, an e-billing report, a referral list and a payroll extract all present as one-off spreadsheets and turn into monthly ones.
The moment that is true, the work is no longer an import. It is a standing job with a transformation step, an error-triage step and a verification step, and the only real question is whether a person or a process owns it.
Where Caddi fits
Caddi takes the routine over once the file recurs. Show it the load the way you do it now, spreadsheet cleanup included, and it runs the whole loop on a schedule: pull the file, apply the transform, upsert through the API, triage the failures against your rules, and report what changed. The five habits above stay; nobody has to remember them each month.
Related: Import Wizard vs Data Loader, Salesforce ETL tools, and CRM data entry automation.
The recurring half
See a monthly spreadsheet load automated
Caddi handles the cleanup, the upsert and the error triage, and reports what changed each run.
Frequently asked questions
How do I import an Excel file into Salesforce?
Save it as CSV in UTF-8, then use the Data Import Wizard for up to 50,000 records on a supported object, or Data Loader for anything larger or on any other object. Add an external ID column and load with upsert so a rerun updates rather than duplicating.
Why did my Salesforce import create duplicates?
Almost always because the load used insert rather than upsert on an external ID. Without a stable key, Salesforce has no way to know the row already exists, so every rerun creates a new record.
What is an external ID and why does it matter?
A field marked as an external ID holds a stable identifier from the source system. It lets you upsert, which means the same file can be loaded repeatedly without creating duplicates, and it lets child records reference parents without knowing Salesforce IDs.
Should I test the import first?
Yes, and with the full file rather than a sample. Sample loads pass and full loads fail, because the failures come from volume-dependent things: API limits, required-field collisions on unusual rows, and attachment sizes.