Salesforce Data Loader export: a step-by-step guide with a manifest

What is Salesforce Data Loader and when is it the right export tool?#

Salesforce Data Loader is a client application from Salesforce that inserts, updates, upserts, deletes and exports records in bulk through the API, writing exports to CSV files. It is the right tool when you need object-level exports you control field by field, with SOQL filters, Export All for deleted and archived rows, and a run you can repeat exactly.

Salesforce's current guide says Data Loader supports CSV files of up to 150,000,000 records and suggests the web-based import wizards for smaller jobs, such as fewer than 50,000 records. Larger orgs still export big objects in date slices, which also makes each file easier to verify.

Data Loader runs on your machine and needs a Java runtime. Salesforce officially supports it on Windows and macOS; the open-source project documents a Linux route, but Linux is unsupported. Batch (command-line) mode is officially supported only on Windows, which matters if you want scheduled, scripted exports.

Data Loader vs Data Export Service vs dataloader.io: which should you use?#

Use Data Loader for controlled, object-by-object exports with SOQL; use the Data Export Service for a whole-org backup ZIP on a weekly or monthly cadence; use dataloader.io if you want a browser-based tool with no install. They are different products and not interchangeable for a documented dataset inventory.

The Data Export Service (Setup, Data Export) packages CSV files for the whole org on a weekly or monthly schedule; see what the Salesforce weekly export includes and leaves out for its scope and limits.

Dataloader from MuleSoft (dataloader.io) is a separate, browser-based product that needs no installation. Salesforce's own documentation contrasts it with the downloadable Salesforce Data Loader. This guide covers the desktop Data Loader only.

How do you install Data Loader and log in?#

Install a supported Java runtime first, download Data Loader from Salesforce, run the installer, then log in to Production or Sandbox. Salesforce's current installation guide asks for Java Runtime Environment 17 or later (for example Azul Zulu or Eclipse Temurin) and a user with the API Enabled permission.

To export, the user also needs read access to the records. Data Loader exports only what that user can see, so run inventory exports as a user whose profile or permission sets can read every object and field in scope, or you will get silently partial files.

• 1Install Java 17 or later and confirm with java -version. Salesforce's guide also has you set JAVA_HOME to the JRE directory.
• 2Download the current Data Loader release from Salesforce's developer tools page, extract the ZIP and run install.bat on Windows or installer.command on macOS.
• 3Launch Data Loader and choose Production or Sandbox before logging in; the default endpoints are login.salesforce.com and test.salesforce.com.
• 4Log in to your org. You stay logged in until you log out or close the program.
• 5Open Settings, Settings and set the export options described below before your first run, not halfway through the inventory.

Which Data Loader settings should you fix before exporting?#

Fix encoding, time zone, batch size and API mode once, record them in the manifest, and do not change them between runs. Data Loader stores settings in a properties file whose location appears under Settings, Help, so you can copy that file into the inventory folder as evidence.

The defaults below come from the current Data Loader guide and the open-source Data Loader code that Salesforce publishes on GitHub. Defaults can change between releases, which is exactly why the manifest records the version and the settings file.

What is the step-by-step Salesforce Data Loader export procedure?#

Run one object at a time: Export or Export All, choose the object, name a new CSV, build or paste the SOQL, review it, and finish. Data Loader then shows a summary with success and error files. The steps below follow the Salesforce Data Loader export guide, with inventory controls added.

• 11. Click Export for live records, or Export All to also include soft-deleted records still in the Recycle Bin and archived activity records. The same commands are in the File menu.
• 22. Choose the object. If it is not listed, select Show all objects; history objects such as OpportunityFieldHistory and CaseHistory and file objects such as ContentVersion appear there.
• 33. Choose the output CSV. Always use a new file name for each run so earlier output is never overwritten or confused. A pattern like opportunity_exportall_2019-01-01_2019-12-31_v1.csv documents itself.
• 44. Select fields. Include Id and every relationship ID (AccountId, OwnerId, ContactId, WhatId, WhoId, ParentId, RecordTypeId) plus CreatedDate, LastModifiedDate and SystemModstamp. For compound address fields, select the component fields (BillingStreet, BillingCity and so on).
• 55. Add conditions or edit the generated SOQL directly. With no conditions, Data Loader returns every record you can read. For large objects, slice by date, for example WHERE CreatedDate >= 2019-01-01T00:00:00Z AND CreatedDate < 2020-01-01T00:00:00Z.
• 66. Copy the final SOQL into the manifest before clicking Finish, then confirm the run.
• 77. When the summary appears, record the success count and keep any error file. Rename nothing after this point; compute the checksum on the exact file you will ship.

Which objects make a complete CRM history export?#

A complete history needs the core records, the activity records attached to them, the field history tables, and file metadata, each exported with its relationship IDs. Exporting only Accounts and Opportunities gives you a snapshot, not a history.

Field history is the usual gap. Salesforce keeps tracked field history for 18 months in the UI and up to 24 months through the API; use Export All, select Show all Salesforce objects and choose the history object. Field history Salesforce has deleted is not included, and orgs with Field Audit Trail keep archived history in the FieldHistoryArchive big object, which needs its own export. For retention limits, see Salesforce field history retention.

Support objects (Case, CaseComment, EmailMessage, feeds) are covered in exporting Salesforce case history with feeds, emails and comments. Files need two steps: Data Loader exports ContentVersion, ContentDocument and ContentDocumentLink rows, but Salesforce's export guide says it does not support exporting attachments, so plan the file bodies through the Data Export Service or a separate API job and join them back by ContentDocumentId.

What should an export manifest record?#

One row per run, written at the time of the run, with enough detail that someone else could rerun the same SOQL and get the same count. Keep the manifest as a CSV next to the data files, and keep the Data Loader settings file and success logs in the same folder.

The template below uses illustrative values only. Generate checksums with sha256sum on Linux, shasum -a 256 on macOS or certutil -hashfile <file> SHA256 on Windows.

How do you check that a Data Loader export is complete?#

Compare each file's row count with an independent count from Salesforce, confirm every relationship ID resolves to a row in another file, and confirm history and file objects were exported for the same period. Do this per object before anyone downstream touches the data.

• 1Counts match: run SELECT COUNT() FROM <object> WHERE <same filter> or a report with the same filter, and compare with the success count. Reports only count what the report type and the running user can see, so compare like with like.
• 2Slices add up: the sum of yearly or monthly slices equals the full-object count, with no overlapping or missing boundary days.
• 3Relationship IDs kept: AccountId, ContactId, OwnerId, WhatId, WhoId, ParentId and ContentDocumentId are present in every file that has them, and a sample join finds the parent row.
• 4Field history included: every object with tracked fields has its history file for the same date range, and the earliest history date is noted (expect about 18 to 24 months unless you have Field Audit Trail).
• 5Deleted and archived rows handled: Export All files keep the IsDeleted column, and the manifest says whether deleted rows will be kept or filtered.
• 6Encoding and dates verified: open a file with accented names to confirm UTF-8, and check one record's CreatedDate against the Salesforce UI to confirm time zone handling.
• 7Visibility confirmed: the exporting user can read every field you expected; a column that is entirely blank is often a field-level security gap.
• 8Checksums recorded: every file in the manifest has a hash, and the hash is recomputed after any copy or transfer.

How can you make the export repeatable?#

Save the exact SOQL per object, keep the settings file, and, if you are on Windows, script the runs in batch mode so the next export uses identical parameters. Batch mode reads a process-conf.xml where each process sets the operation (extract or extract_all), the object, the SOQL in sfdc.extractionSOQL and the output file.

For incremental refreshes, filter on SystemModstamp or LastModifiedDate greater than the previous run's timestamp and use Export All so deletions since the last run are captured. Record each incremental run as its own manifest row instead of overwriting the baseline.

What changes when the export is for licensing or a dataset inventory?#

Being able to export data is an access question; whether you may share or license it also depends on privacy permissions, ownership and contract rights, and de-identification alone does not create a right to license. A well-documented export makes those reviews faster because reviewers can see which objects, fields and periods exist. SourceX runs sourcing, rights review, contracting, data preparation, delivery and payment for businesses licensing operational data to AI developers, starting with a short assessment and no data uploads; the company approves what is released. See the four-permission framework before sharing any export.