Study guide
3.4 Data Import & Export for Development
Salesforce Certified Platform Developer I Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy
2 Platform Fundamentals
2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations
3 Data Modeling & Schema
3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development
4 Platform Data Features
4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries
5 Declarative Process Automation
5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools
6 Apex Language Basics
6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns
7 SOQL, SOSL & DML
7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries
8 Apex Triggers & Order of Execution
8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control
9 Asynchronous Apex
9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration
10 Security, Events & Schema Access
10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)
11 Visualforce
11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience
12 Lightning Components
12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events
13 UI Composition & Apex Integration Patterns
13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce
14 Apex Testing
14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences
15 Debugging & Developer Tools
15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy
16 Deployment & Release
16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance
3.4 Data Import & Export for Development
Key Takeaways Explain This Topic AI
Data Import Wizard suits smaller, simpler loads for supported objects; Data Loader handles large volumes, more objects, export, delete, and upsert
Workbench and Salesforce CLI provide flexible API-level import/export for developers; scratch orgs often use seed scripts and CLI data commands
Upsert and matching rely on Id or External ID fields; design External IDs before bulk loads
Watch API request limits, batch sizes, partial success, and duplicate matching rules during loads
Choose tools based on volume, object support, need for automation, and whether the target is a scratch, sandbox, or production-like org
Last updated: August 2026
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.
- Tool Best for Weak for
- Import Wizard Simple guided imports, smaller sets Complex objects, huge volume, full export control
- Data Loader Large ETL-style load/export/upsert/delete Casual one-off mapping without CSV discipline
- Workbench Ad hoc SOQL, short API experiments Repeatable enterprise ETL
- Salesforce CLI Scripted seed data, CI, scratch orgs Heavy interactive mapping UI
- 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:
- Create scratch org from project config
- Push source (metadata includes schema)
- Run seed script: CLI data import, Apex anonymous, or both
- 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
- Concern Why it matters
- API request limits Large loads consume daily API or bulk job capacity
- Batch size Too large can hit payload or timeout issues; too small is chatty
- Partial success Some records succeed while others fail—always inspect error files
Triggers/flows/validation Each inserted row runs automation—can cause CPU timeouts or validation failures mid-load
- Order of load Parents before children; junction rows after both parents
- Picklist & restricted values Invalid picklist values fail rows
- Record types May need RecordTypeId column for correct business process
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.