No. Each Data Loader job — Insert, Update, Upsert, Delete, Hard Delete, or Export — targets exactly one Salesforce object. You pick the object in the wizard, and the CSV maps to that object alone.
This isn’t a limit of the API; it’s a deliberate design choice in the GUI. The job’s success/error files are scoped to the one object so you can clearly see what happened.
What multi-object work actually looks like
If you’re migrating Accounts, Contacts, Opportunities, and Cases into a new org, that’s four separate Data Loader jobs, run in the right order:
- Load Accounts first. Capture their new Salesforce Ids from
success.csv. - Load Contacts, populating
AccountIdfrom the captured map. - Load Opportunities, again wiring
AccountId. - Load Cases, wiring
AccountIdandContactId.
The pattern is “parents before children, capture Ids in between”. Upsert with External Ids simplifies this enormously — you can wire children to parents by external key without an Id-capture step.
Ways to chain jobs without manual clicking
- Data Loader CLI —
process.bat/process.shruns a saved configuration. Chain multiple configs in a batch script and you have a multi-object load. This is the standard pattern for nightly ETL. - PowerShell / shell scripts that run several CLI invocations sequentially.
- Scheduler tools (Windows Task Scheduler, cron) that fire the chain on a timetable.
Tools that can do multi-object loads
If single-object jobs are too painful for your use case, look outside Data Loader:
- dataloader.io — web tool with multi-object workflow support.
- Workbench — single-object too, but a faster web UI for one-off jobs.
- MuleSoft / Jitterbit / Informatica — full ETL platforms that handle dependency graphs natively.
- SFDX / Salesforce CLI plan files —
sf data tree import --planreads a JSON plan with multiple sObjects and resolves references between them. - Custom Apex — for orgs that need transactional all-or-nothing loads,
Database.insert(records, allOrNone)with mixed sObject lists handles it in one transaction (within governor limits).
What the interviewer wants
The grading point is honesty. The Data Loader UI does not load multiple objects in one go. Recognising that — and naming the workarounds (CLI chaining, External-Id upserts, ETL tools, sf data tree) — shows you’ve done real-world migration work.
Tip: use External Ids to avoid Id-shuffling between jobs
The cleanest multi-object load:
- Add
Legacy_Id__c(External Id, Unique) to every object. - Populate it with your source-system primary key in each CSV.
- Reference parents in child CSVs with
Account.Legacy_Id__cinstead ofAccountId.
Run Upsert in dependency order and you never have to copy a Salesforce Id between files.
Verified against: Data Loader Guide, Salesforce CLI Command Reference — sf data tree, Metadata API Developer Guide. Last reviewed 2026-05-17 for Spring ‘26 release.