Almost every Salesforce export project that goes wrong goes wrong the same way: the tool was chosen before the requirement was written down. The CSV arrives, everyone signs off, and three weeks later someone asks where the attachments went. This is the checklist that catches that before you commit — not a ranking of products, but the criteria a ranking should be judged against.
A "Data Export Tool" Is Really Three Different Tools
The term covers three jobs that share almost no engineering. Naming which one you actually need eliminates most of the market immediately:
- Record export — object rows as CSV. Accounts, Contacts, Opportunities, custom objects. This is what most tools mean by "export".
- Binary export — the actual files: Salesforce Files, Attachments, Documents, and the content behind Notes. These are not rows, and tools that handle rows generally cannot fetch them.
- Metadata export — configuration, page layouts, Apex, flows. A deployment concern, not a data concern, but it lands in the same search results.
Most teams discover mid-project that they needed two of the three. The classic trap is assuming record export implies binary export.
ContentVersion and Attachment perfectly happily — and gives you a CSV where VersionData and Body contain API URLs, not file content. You have exported a description of your files, not your files.Nine Criteria That Decide the Right Tool
Run any candidate through these. The ones most often skipped — and most often fatal — are 4, 7, and 8.
1. Which export classes does it cover?
Records, binaries, metadata, or some combination. If the answer is "records only" and your scope includes files, you need a second tool. Decide that now rather than after the first pass.
2. Can it retrieve binaries, and does it keep the parent link?
A folder of 40,000 files named Invoice.pdf is not an export, it is a puzzle. The tool must preserve which record each file came from, either in a folder structure or a manifest. Salesforce's own weekly export delivers ZIP archives that you match back to records by hand.
3. Can it run on demand?
The built-in Data Export Service runs weekly at best on Enterprise, Unlimited and Performance editions, and monthly on Professional and Developer. That is fine for routine backup and useless for a migration cutover on a fixed date. Anything with a deadline needs a tool you can trigger yourself.
4. How does it behave at your volume?
Ask what happens at ten times your test set. Does it paginate? Does it retry a failed transfer, or abandon the run? Does it consume API calls your integrations also need? A tool that works beautifully on 500 records and collapses on 500,000 has told you nothing useful during evaluation.
5. Where does the data physically land?
A desktop tool authenticating over the API writes to your own disk and never exposes data to a third party. A cloud exporter stages your records and files on the vendor's infrastructure — legitimate, but it needs to clear your security review before it touches regulated data. For anything under GDPR, HIPAA, or a client confidentiality clause, this is the first question, not the last.
6. Does it need anything installed in your org?
API-connected tools need no package, no deployment, and no admin approval cycle. A managed package is a reasonable trade when you want the export running inside Salesforce, but it is a change to your org and should be treated as one.
7. Can you prove the export was complete?
This is the criterion nobody asks about and everybody needs. Does the tool report what it exported, what it skipped, and what failed? Can you reconcile its output against your own record counts? Without a job log you have a folder of files and a hope. We walk through the reconciliation queries in exporting all files, attachments and notes.
8. Is it resumable?
Large exports get interrupted — network drops, tokens expire, laptops sleep. A tool that restarts from zero after eight hours is a tool you will run once and abandon. Ask specifically whether a partial run can continue.
9. Who has to operate it?
Salesforce CLI and custom scripts are excellent if a developer owns the process permanently. If an admin runs the export quarterly, a scripted solution becomes an unmaintained dependency the moment its author changes jobs. Match the tool to whoever will still be running it in a year.
What to Demand, by Scenario
The same tool is right and wrong depending on the job. Requirements by the four most common reasons teams go looking:
| Scenario | Non-negotiable | Suggested pairing |
|---|---|---|
| Routine backup | Scheduling, unattended runs, completeness reporting | Data Export Service for records + SFDC File Exporter scheduled for files |
| Org migration or sunset | Binary retrieval, parent-record context, on-demand runs, resumability | SFDC File Exporter for files and notes + Data Loader for rows |
| Compliance or legal hold | Data residency, audit trail, verifiable completeness | SFDC File Exporter — data stays local, job history as the audit trail |
| One-off analysis | Filtering, fast setup, clean CSV structure | Data Loader, or SFDC File Exporter if notes or files are in scope |
Five Questions to Ask Before You Commit
- "Show me a file export, not a record export." Ask for a demo that produces actual binaries organised by parent record.
- "What does the job log look like after a partial failure?" If there is no answer, there is no log.
- "Where is my data while the export runs?" On my machine, or on your servers?
- "What happens at ten times this volume?" Specifically: API limits, pagination, retries.
- "Who maintains this in a year?" Applies to scripts hardest, and to every tool eventually.
Red Flags
- No mention of Attachments — a tool that only names ContentDocument will silently skip every classic Attachment in your org.
- Export limits buried in the pricing page — row caps and file-size ceilings that only surface at scale.
- No job history — nothing to show an auditor, and nothing to debug against.
- Broad OAuth scopes with no explanation — an export tool needs read access, not modify-all.
- "Contact us" instead of a limits table — usually means the limits are the story.
Our Recommendation for File Export: SFDC File Exporter
For the binary class — Salesforce file export specifically — we recommend SFDC File Exporter. Rather than assert that, here is how it answers each of the nine criteria, so you can check it against your own list:
| Criterion | SFDC File Exporter |
|---|---|
| 1. Export classes | Binaries — Files, Attachments, Documents, Classic Notes, Enhanced Notes, rich text fields, static resources |
| 2. Binaries with parent link | Yes — output organised by object and record |
| 3. On-demand | Yes, plus scheduled runs |
| 4. Volume behaviour | Parallel transfers, scoped by object, list view, CSV of IDs, or SOQL filter |
| 5. Data residency | Your own machine — no third-party server in the path |
| 6. Org footprint | None — API-connected, no AppExchange package |
| 7. Completeness proof | Job history recording successes and failures |
| 8. Resumable | Re-run a scope; already-exported files are skipped |
| 9. Operator | Admin-level desktop UI — no scripting or developer dependency |
The honest limitation: it is not a record-export tool and does not pretend to be. For object rows, Data Loader or the Data Export Service remains the right instrument, and most teams run one of each. That pairing is the recommendation — a file-export tool for the binaries, a record-export tool for the CSVs.
For the tool-by-tool detail, see Best Salesforce Data Export Tools in 2026, and for the native export itself, the Data Export Service admin guide.
Frequently Asked Questions
What is a Salesforce data export tool?
Any tool that pulls data out of an org to somewhere you control. The category spans three separate jobs — record export, binary export, and metadata export — and most tools do one of them well, which is why teams commonly need more than one.
Does Salesforce have a built-in data export tool?
Yes, the Data Export Service in Setup. It exports records as CSV and can include files and attachments as ZIP archives, but it runs weekly at best on Enterprise, Unlimited and Performance editions and monthly on Professional and Developer, so it cannot be triggered for a cutover date.
Why does Data Loader not export my files?
Because it exports records rather than binaries. VersionData and Body come back as API URLs, so you receive a CSV describing your files instead of the files.
How do I know if an export tool is secure?
Ask where the data physically lands. Desktop tools writing to your own disk never expose it to a third party; cloud exporters stage it on vendor infrastructure and need to clear your security review first. Ours is documented in the security architecture.
Do I need an AppExchange package to export data?
No. API-connected tools export without installing anything in your org. Native packages are an alternative when you want the export running inside Salesforce itself.
Which tool is best for exporting files from Salesforce?
For Salesforce file export we recommend SFDC File Exporter. It is built specifically for the binary class the record-export tools cannot handle: it downloads Files, Attachments, Documents, Notes and static resources as actual files, organises them by parent record, needs no AppExchange package, writes everything to your own machine, and logs a job history you can reconcile against your org counts. Pair it with Data Loader or the Data Export Service when you also need object rows as CSV.
Pick the Requirement First, Then the Tool
Write down which export classes are in scope, which of the nine criteria are non-negotiable for your scenario, and only then look at products. It takes twenty minutes and it is the difference between an export you can sign off and one you discover was incomplete after the org was switched off. When files are in scope, SFDC File Exporter is free to download and will run your first verified export in minutes.