Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryBBasic Data Import
AdministrationBeginner

Basic Data Import

Basic Data Import is the Salesforce wizard for importing small to medium volumes of records (up to 50,000 records per import) into standard or custom objects.

§ 01

Definition

Basic Data Import is the Salesforce wizard for importing small to medium volumes of records (up to 50,000 records per import) into standard or custom objects. Admins upload a CSV file, map the columns to Salesforce fields, decide between insert, update, or upsert behavior, and run the import. The wizard handles common objects (Account, Contact, Lead, Solution, and one custom object per import session) and offers field mapping suggestions plus duplicate detection. It is the simpler counterpart to Data Loader, which handles larger volumes and more advanced patterns.

Basic Data Import covers the everyday data load scenarios most admins face: importing a list of leads from a marketing event, adding contacts from a partner spreadsheet, updating account fields from an external system export. The 50,000 record cap and the limited object support are the boundaries; beyond those, Data Loader, Bulk Data Load Jobs, or a custom integration is the right tool. Most admin teams use Basic Data Import for weekly to monthly data loads and reserve heavier tools for mass migrations and integrations.

§ 02

Why Basic Data Import is the right tool for the everyday data load

Where Basic Data Import lives and what it supports

Setup, Data, Data Import Wizard, Launch Wizard. The wizard supports Account, Contact, Lead, Solution, Person Account, and any one custom object per session. Each session is a single CSV file mapped to one object type; importing both Accounts and Contacts from one combined file requires two sessions or Data Loader. The CSV must use UTF-8 encoding, comma-separated, with a header row. Field mapping is one column to one Salesforce field; transformations or computed mappings need to happen before the upload or in Data Loader where formulas are supported.

Insert, update, and upsert behavior

Three import modes. Insert creates new records and ignores matching existing records (useful for one-time loads where uniqueness is enforced externally). Update modifies existing records and ignores rows that do not match any existing record (useful for field updates from external systems). Upsert (Insert/Update) updates matching records and creates new ones for non-matches (the most common production pattern). Match is by Salesforce ID, by external ID field (custom field marked External ID), or by the wizard's built-in duplicate matching rules (name plus email for Contact, name plus website for Account).

Duplicate detection and the Match Type decision

Basic Data Import integrates with Duplicate Management; matching rules configured at the object level apply during import. The Match Type setting on the wizard tells it which field combination to match on. The default for Contact is Email; alternatives include Name, External ID, Salesforce ID. Mismatches in Match Type produce silent duplicates (the import creates a new record because the match field did not align with existing data). Always verify Match Type against the actual matching rule on the object before running an import larger than 100 records.

Field mapping and the auto-map convenience

The wizard auto-maps CSV columns to Salesforce fields when the column header matches a field label or API name. Auto-mapping handles 80 percent of typical imports; manual mapping covers the rest (custom field columns, columns with non-standard names). The wizard supports mapping a single CSV column to multiple Salesforce fields (rare but useful for denormalized data) and supports leaving CSV columns unmapped. Validation runs during the mapping step; if a required field is unmapped or a picklist value does not exist in the org, the wizard flags the issue before the import starts.

Triggers, automation, and the import-time behavior

Records imported through Basic Data Import fire the same triggers, validation rules, workflow rules, processes, and Flows as records created any other way. This is usually correct (you want the same validation to apply) but occasionally surprising (a 5,000-record import that triggers a Flow that sends an email per record produces 5,000 emails). Always check what automation fires on insert and update for the target object before running a large import. The wizard does not have a "skip triggers" option; that flexibility lives in Data Loader through the API options.

Limits and when to graduate to Data Loader

Hard limits: 50,000 records per import session, single object per session, no support for attaching files or attachments, no support for hard-delete or undelete operations, no support for complex sObject types like Opportunity Line Item. Soft limits: no scripting, no scheduling, no command-line invocation. Graduate to Data Loader when any of those constraints bind. Data Loader handles up to 5 million records per batch, supports more objects (including Opportunity Line Item, Asset, custom junction objects), supports scheduled imports via the CLI, and integrates with deployment pipelines.

Post-import verification and the audit trail

The wizard sends an email summary when the import completes. The summary lists records created, records updated, records that failed, and a downloadable error log for failures. The error log is the primary debugging artifact; it shows row number, error message, and the original CSV data per failure. Common errors: validation rule failures, duplicate detection blocks, required field violations, foreign key lookups to records that do not exist. Save the error log, fix the underlying issues, and re-run only the failed rows; never re-run the entire CSV because successful inserts on the first run will duplicate.

§ 03

How to run a clean import with Basic Data Import

The successful pattern: clean the CSV, test on 10 rows in a sandbox, run full import in production, verify the email summary, address failures. The failed pattern: run a 5,000-row import in production without testing and spend the next two days reversing the damage.

  1. Clean the CSV before upload

    Validate column headers, confirm picklist values exist in the org, verify required fields have values, check date formats match Salesforce expectations (YYYY-MM-DD), confirm UTF-8 encoding.

  2. Test on 10 rows in a sandbox

    Subset the CSV to 10 representative rows. Run the import in sandbox. Verify field mapping, automation behavior, and error handling. Sandbox first is non-optional for any import over 100 rows.

  3. Decide the import mode

    Insert, Update, or Upsert. Pick deliberately; the wrong choice creates duplicates (Insert when you meant Upsert) or silently skips records (Update when records do not match).

  4. Run the production import in off-hours when feasible

    Imports that fire downstream automation can slow the org for other users. Off-hours runs reduce user impact; not always possible, but worth considering.

  5. Verify the email summary

    Salesforce emails a summary on completion. Check records created, updated, failed. The numbers should match expectations; significant deviations indicate the import behaved differently than planned.

  6. Download the error log and fix failures

    The error log shows row-level failures with reasons. Fix the underlying data issues. Build a corrected CSV with only the failed rows; never re-run the entire original CSV.

  7. Document the import in your change log

    Date, target object, record count, who ran it, why. The audit trail matters when downstream issues surface weeks later.

Key options
Import moderemember

Insert, Update, or Upsert. Drives whether the wizard creates new records, updates existing ones, or both.

Match Typeremember

Field combination used to match CSV rows to existing records (Salesforce ID, External ID, Name+Email, etc.).

Field mappingremember

CSV column to Salesforce field mapping. Auto-mapped where headers match field labels.

Object scoperemember

Single object per import session. Combined Account+Contact imports require two sessions or Data Loader.

Automation behaviorremember

Triggers, validation rules, workflows fire on imported records. No skip-triggers option; use Data Loader if needed.

Gotchas
  • Match Type misalignment creates silent duplicates. Always verify the wizard's Match Type against the object's actual matching rule before running.
  • Triggers and Flows fire on imported records. A 5,000-record import with a per-record email Flow produces 5,000 emails; check downstream automation before importing.
  • Hard limit of 50,000 records per session. Larger imports require Data Loader.
  • Re-running the full CSV after partial failure creates duplicates of the successful rows. Build a corrected CSV with only the failed rows for retry.
  • Date format mismatches are a common failure mode. YYYY-MM-DD is the safe format; other formats may import as null or as the wrong date depending on org locale.
§

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Basic Data Import.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.

§

Test your knowledge

Q1. Can a Salesforce admin configure Basic Data Import without writing code?

Q2. In which area of Salesforce would you typically find Basic Data Import?

Q3. Why is understanding Basic Data Import important for Salesforce admins?

§

Discussion

Loading…

Loading discussion…