3.4 Data Import & Export for Development

3.4 Data Import & Export for Development

Quick Answer: Use the Data Import Wizard for guided, lower-volume loads of common objects; Data Loader for large CSV extract/load including upsert/delete; Workbench for ad hoc API queries and inserts; and Salesforce CLI data commands plus scripts to seed scratch orgs and automate sandbox setup. Always plan External IDs, matching, batch sizes, and partial success.

Developers constantly move sample data between orgs. Platform Developer I expects familiarity with the tool landscape and the data-quality issues that break Apex tests and demos.

Data Import Wizard

The Data Import Wizard (Setup) is a browser UI for importing data into many standard objects and custom objects.

Strengths:

• Guided mapping of CSV columns to fields
• Available to admins without installing a desktop client
• Can find matching records using simple match options on supported objects
• Good for hundreds to low tens of thousands of records depending on object and org limits

Limitations:

• Not every object or operation is supported (less flexible than Data Loader)
• Not ideal for complex automation or very large volumes
• Export is not its primary job—pair with reports or other tools for extract

Dev use case: Quickly load Accounts/Contacts or a custom object sample set into a sandbox for manual testing when volume is modest.

Data Loader

Data Loader is a client application (and there is also a command-line mode) that uses the Salesforce API for insert, update, upsert, delete, hard delete (with permission), and export.

Strengths:

• Handles large volumes (bulk API options for very large sets)
• Broad object coverage compared to the Import Wizard
• Upsert with Id or External ID matching
• Export/query extract for backup or migration between sandboxes
• Success and error CSVs for troubleshooting

Considerations:

• Requires correct API field names in CSV headers
• Date/time formats, boolean values, and relationship fields (parent Ids or external ID relationship syntax) must be precise
• Bulk API vs SOAP API mode affects batching and governor-style API usage patterns
• User needs appropriate permissions (API Enabled, object CRUD, FLS)

Dev use case: Load 50k test rows, upsert nightly reference data, export sandbox data for analysis, or delete botched imports.

Workbench

Workbench (web tool against your org session) lets developers run SOQL/SOSL, browse metadata, and perform data insert/update/upsert/delete via REST/Bulk style interactions.

Strengths:

• Fast ad hoc queries and small data operations without installing Data Loader
• Helpful for verifying API names, relationship queries, and field values while coding
• Can export query results

Cautions:

• Treat it as a power tool—easy to modify or delete real data in the wrong org
• Session and environment discipline matter (production vs sandbox)
• Not a substitute for version-controlled seed scripts

Salesforce CLI Data Commands and Scratch Org Seeding

Modern DX workflows use Salesforce CLI (sf / legacy sfdx) to:

• Authenticate to scratch orgs, sandboxes, and production
• Import/export tree-structured data (for example, data import/export commands that preserve parent-child relationships via plan JSON and sObject tree patterns)
• Automate seed data after sf org create scratch so every developer gets the same reference records
• Combine with anonymous Apex or Apex test factories for deeper fixtures

Scratch org patterns:

1. Create scratch org from project config
2. Push source (metadata includes schema)
3. Run seed script: CLI data import, Apex anonymous, or both
4. Assign permission sets and run tests

Store seed CSVs/JSON in the repo when they are non-sensitive sample data. Prefer External IDs in seed data so re-runs upsert cleanly instead of duplicating rows.

Matching, External IDs, and Upsert

Successful loads depend on identity strategy:

• Insert always creates new rows—rerunning the same CSV duplicates data unless you match
• Update requires Salesforce Id
• Upsert matches on Id or an External ID field—this is why schema design in 3.1 marks ERP keys as External ID
• Relationship fields can load via parent Salesforce Id or, in many tools, via related External ID reference syntax

Duplicate matching rules and duplicate rules may block or alert on inserts—dev orgs often relax rules, but production-like sandboxes should mirror real constraints so Apex integration code is tested against them.

API Limits, Batches, and Partial Success

Disable or carefully control non-essential automation when bulk-loading large dev datasets (where org policy allows), or design automation to be bulk-safe so loads succeed.

Partial success mindset: Never assume a 10,000-row job fully applied. Use success/error CSVs, re-run corrected error files, and prefer upsert for idempotent reloads.

Export for Development

Common export paths:

• Data Loader export / bulk extract
• Report export (quick, limited)
• Workbench query
• CLI data export / tree export for relational seed snapshots
• Weekly export service (org backup—less of a day-to-day dev tool)

Mask or avoid exporting PII into shared repos. Use fake seed data for public projects.

Choosing a Path (Exam-Style)

• Business user loads 2,000 leads with mapping help → Data Import Wizard
• Developer upserts 200,000 custom rows by External ID → Data Loader (Bulk API)
• Quickly check SOQL and patch a few records → Workbench or CLI query
• Team onboarding: new scratch org with metadata + sample graph of Accounts/Contacts/custom children → CLI data import / seed scripts
• Need delete of failed import set → Data Loader delete with Id extract

Data tools do not replace good schema: without External IDs, clear relationships, and valid picklists, every import path fails the same way. Pair this section with 3.1–3.3 when designing loadable, Apex-friendly models.