Data Import Wizard vs Data Loader: loading Salesforce data safely

For a one-off file under 50,000 records, the Data Import Wizard in Setup is usually the safer choice. It covers leads, contacts, accounts and custom objects. It has built-in matching and simple controls over automation. Use Data Loader when the object isn't supported, the file is larger, or you need update, upsert, delete or a repeatable mapping. Either way, the tool matters less than the file preparation, a test batch and a saved copy of the data you're about to change.

Who is this guide for?

It's for admins and operations staff who load data into a live org on a regular basis. Think event attendee lists, purchased prospect lists, territory changes or a weekly file from another system.

A one-time move from an old CRM is a bigger project with its own plan; our data migration checklist covers it.

What can the Data Import Wizard handle?

The wizard is the browser-based import tool in Setup. Salesforce documents a limit of 50,000 records per import and up to 90 fields per record.

The objects it supports depend on your edition. Typically they include business accounts and contacts, person accounts, leads, campaign members, solutions and custom objects. To see the current list for your org, search for Data Import Wizard in Setup.

• Operations: add new records, update existing ones, or both in one pass. It can't delete records.
• Matching: contacts and leads can match on Salesforce ID, name or email. Business accounts match on Salesforce ID, external ID, or name plus site. Custom objects match on name, Salesforce ID or external ID.
• Automation control: a checkbox decides whether workflow rules and processes fire for imported rows. For leads you can also pick an assignment rule.
• Campaigns: lead and contact imports can add people to a campaign with a member status in the same run.

When do you need Data Loader instead?

Choose Data Loader when the wizard can't reach the object, can't do the operation, or can't cope with the volume. It's also the better fit when the same mapping runs on a schedule.

Data Loader is a desktop client for macOS and Windows. Salesforce releases a new version with each platform release and supports only the latest one. It does insert, update, upsert, delete and hard delete, plus export and export all.

• Volume: the current Data Loader Guide states support for files of up to 150 million records when Bulk API 2.0 is turned on.
• Bulk API settings: Bulk API and Bulk API 2.0 load asynchronously and suit large files. Some settings, such as writing blank values as nulls, behave differently in bulk mode. There you use #N/A in the CSV to clear a field.
• Command line: scheduled, unattended loads are possible from the command-line interface, which Salesforce documents as Windows only.
• Hard delete: removes records without passing through the Recycle Bin. It needs Bulk API enabled plus the Bulk API Hard Delete permission.

Is there a browser version? The Salesforce-native Data Loader is still a desktop app. Salesforce also offers a separate web-based loading service with its own plans. Check what your org is licensed for with your Salesforce account team.

Where do third-party and ETL tools fit?

Third-party tools earn their place when a manual CSV has become a recurring process between systems. At that point, a scheduled sync or an integration is usually safer than a person with a spreadsheet.

• Browser-based loaders: add-on apps that run in the browser, often with saved jobs, scheduling and lookups by name rather than ID.
• ETL and integration platforms: extract, transform and load data on a schedule with logging, retries and alerts.
• Spreadsheet connectors: let analysts pull and push records from a familiar spreadsheet, which is convenient but harder to govern.

Check any tool's security review, where data is processed, and which user it connects as before approving it.

How should you prepare the import file?

Most failed imports trace back to the file, not the tool. Keep a template and checklist for each recurring import.

• Record IDs: updates need the Salesforce ID. Use the 18-character version, which survives spreadsheet case changes. Export the target records first to get them.
• External IDs: for upserts, mark a custom field as External ID, ideally unique, and fill it with the source system's key.
• Picklist values: match the API value exactly. An unknown value may be rejected, or quietly stored if the picklist isn't restricted.
• Dates: Data Loader recommends the yyyy-MM-dd pattern with a time and time zone offset. A European date setting exists for dd/MM/yyyy files.
• Owners and record types: use user IDs and record type IDs, or confirm the tool can match on names.
• Required fields: include every field that a page layout, validation rule or the API requires. Layout requirements don't apply to API loads, but validation rules do.
• Lookups: link to parents by ID or by the parent's external ID. Load parents before children.
• Encoding: save as UTF-8 so accented names survive.

How do you stop an import from creating duplicates?

Decide the match key before you load and make the tool use it. Then review how your duplicate rules respond during a test batch.

In the wizard, pick the matching field that fits the source, such as email for event attendees. In Data Loader, use upsert on an external ID for anything that recurs. Plain insert will happily create a second copy of every row.

Duplicate rules may block or flag records during a load. How they behave varies by tool, API and rule settings, so confirm it in a sandbox. For tuning matching rules and merging what's already there, see our duplicate cleanup guide.

Which automation fires during an import?

Assume everything fires unless you've switched it off. That includes record-triggered flows, Apex triggers, validation rules, duplicate rules and any emails those automations send.

The wizard's workflow checkbox is off by default, and assignment rules apply only if you pick one. Data Loader behaves like any API client, so automation runs as normal. Lead and case assignment rules run in Data Loader only when you enter a rule ID in Settings.

Many orgs add a bypass pattern for loads. A custom permission or hierarchy custom setting is assigned to the import user. Flows, triggers and validation rules check it and skip themselves when it's present.

• Keep the bypass narrow: skip notifications and field defaults that don't make sense for historical data.
• Leave integrity checks on where possible, such as validation rules that protect reporting.
• Assign it only for the duration of the load, then remove it.

How do you test an import safely?

Load a small batch first, check it, then load the rest. For a new import type or a large change, run the whole file in a sandbox before production.

• Pick 10 to 50 rows that cover the edge cases: blanks, long text, odd characters, each record type.
• Load them and open several records. Check owners, lookups, dates and which automation fired.
• Confirm no emails went to customers or prospects that shouldn't have.
• Only then load the remaining rows.

In Data Loader, point the server host setting at the sandbox URL. It's easy to forget to switch it back.

What do you do with the error file?

Fix the rejected rows and reload only those, never the whole file again. Both tools give you a file listing each failed row and the reason.

Data Loader writes a success file and an error file for every run; keep the success file, since it holds new record IDs. Sort errors by message, because one cause usually explains most failures. Typical causes are bad picklist values, missing required fields, validation rules and unmatched lookups.

How do you know who loaded what?

Keep a log of every import and run large or recurring loads under a named integration or import user. That way Created By and Last Modified By tell the story.

• Save the source file, the mapping file and the success and error files together in a dated folder.
• Record who ran it, why, which object, which operation and how many rows succeeded.
• Stamp a source or batch field on each record so the load can be found with a report.

Can you undo a bad import?

Only partly, and only if you planned for it. Salesforce has no undo button for a data load.

Newly inserted records can be deleted using the IDs in the success file. Overwritten values can only be restored from a copy you saved before the load. Before any update or delete, export the affected records with every field. Hard-deleted records skip the Recycle Bin entirely. For restore tools and recovery planning, see our backup and recovery guide.

Which permissions does an import need?

Users need object permissions for the operation, and Data Loader also needs API access. Bulk tools add their own permissions.

• Data Import Wizard: object create and edit rights, plus import permissions that vary by object. Check the help topic for your object.
• Data Loader: API Enabled, plus Create, Edit or Delete on the object as the operation requires.
• Hard delete: the Bulk API Hard Delete permission, with Bulk API turned on.
• Mass delete with Data Loader: Salesforce's guide lists Modify All Data.

Grant these through a permission set assigned to named importers, not through a broad profile. Confirm the exact edition availability with your Salesforce account team, since both tools vary by edition.

Who should be allowed to import?

Fewer people than currently can. Give a small, trained group the rights, and route everyone else's files through them.

• Name an owner for each recurring import, with a written template and checklist.
• Require a test batch and a pre-load export for any update, upsert or delete.
• Reserve delete and hard delete for admins, with a second person reviewing the file.
• Move any import that runs on a regular schedule toward a scheduled integration with monitoring.

These rules belong in your wider data governance policy, alongside data ownership and quality standards.