Salesforce Workbench: How to Use It Safely (No Undo)

Most Workbench disasters are not hacks or bugs. They are a CSV opened in the wrong org. If you work in Salesforce, you will use Salesforce Workbench sooner or later, and the tool will do exactly what you tell it, instantly, on as many records as you give it.

Key takeaways

• Salesforce Workbench is a free, browser-based tool for running SOQL, loading data, calling APIs and moving metadata, built on Salesforce's own APIs.
• It has no undo and no sandbox safety net of its own, so every run should be treated like a small deployment: sandbox first, small batch, backup, then production.
• Use it for quick queries, deleted-record checks and one-off fixes. Use Data Loader or the Salesforce CLI for repeatable or large jobs.
• Most of the real risk sits outside Workbench: automation that fires on your update, and a data file nobody checked.

What is Salesforce Workbench?

Salesforce Workbench is a web-based utility that sits on top of Salesforce's APIs, letting you query, change and inspect an org without installing anything.

You open Workbench, choose Production or Sandbox, pick an API version and log in with your normal Salesforce credentials. From there you can run SOQL, insert, update, upsert, delete and undelete records, explore objects and fields, execute anonymous Apex, call the REST API and retrieve or deploy metadata.

That matters. It's not a Salesforce product with a support contract, so treat it as a sharp tool you're responsible for, not as a managed feature.

My view, and it's a judgement rather than a measurement: Workbench is the best tool for the question "what is actually in this org right now?" It's the worst tool for "change 40,000 records and hope".

What do you need before using Salesforce Workbench?

You need the API Enabled permission, a clear idea of which org you're in, and a reason to use Workbench instead of the UI.

Your profile or permission set must include API Enabled, and Workbench respects your field-level security and object permissions like any other API client. Some things to check first:

1. Which environment am I choosing at login, Production or Sandbox? Read it twice.
2. Does my user have only the access this task needs? An admin with Modify All Data can break more than a user with read-only access.
3. Do I have approval, if this touches production data?

Workbench uses OAuth, so you approve access to a connected app. When you finish, log out in Workbench, and if you were on a shared or borrowed machine, revoke the session in your Salesforce settings.

How to run a SOQL query in Salesforce Workbench

Use Queries > SOQL Query, build or paste your query, and choose the output format before you press Query.

SOQL is Salesforce's query language, documented in the SOQL and SOSL Reference. Here are three queries I'd run on day one in any org.

Recently changed accounts:

SELECT Id, Name, Owner.Name, LastModifiedDate
FROM Account
WHERE LastModifiedDate = LAST_N_DAYS:7
ORDER BY LastModifiedDate DESC
LIMIT 200

Duplicate contact emails:

SELECT Email, COUNT(Id)
FROM Contact
WHERE Email != null
GROUP BY Email
HAVING COUNT(Id) > 1

Deleted accounts still in the Recycle Bin:

SELECT Id, Name, DeletedDate
FROM Account
WHERE IsDeleted = true

For that last one, set the "Include" option to "Deleted and archived records" in Workbench. Without it, deleted rows won't appear. Deleted records stay in the Recycle Bin for a limited time, which Salesforce documents in its help pages, so check the retention period before you promise anyone a recovery.

Two habits save time. Start with LIMIT, then remove it once the query returns what you expect. And select only the fields you need, because wide queries on big objects are slow.

How to export data with Workbench

Run your SOQL, choose the Bulk CSV output, and download the file; for a safety backup, always include Id and every field you're about to change.

The steps:

1. Go to Queries > SOQL Query.
2. Pick the object, select fields and add filters, or paste a query.
3. Set "View as" to Bulk CSV for large result sets, or List for a quick look.
4. Click Query, then download the file when the job completes.

Bulk CSV uses Salesforce's bulk API, described in the Bulk API 2.0 documentation, so it copes with larger volumes than the on-screen list.

This export is also your safety net. Before any update, export the same records with their current values and save the file somewhere you can find it. If the update goes wrong, that file is your rollback.

How to update or delete records in Salesforce Workbench safely

Test on five records in a sandbox, check the results, then repeat in production with a backup in hand.

Workbench's Data menu offers Insert, Update, Upsert, Delete, Undelete and Purge. The steps for an update are the same each time:

1. Prepare a CSV whose first column is Id, followed by only the fields you're changing.
2. Choose Data > Update, upload the file and map the columns to fields.
3. Read the confirmation screen and its options before you click Confirm.
4. Check the results file and spot-check the records in the UI.

Some safety rules people skip:

• Dry-run on a sample. Put five rows in the file first. If it works, run the rest.
• Know what your update fires. Triggers, flows, validation rules and duplicate rules all run on API updates. If you don't know the sequence, read the order of execution in Salesforce first. If a flow errors during your load, debugging a Salesforce flow will help you find the fault.
• Prefer upsert with an External ID when matching records from another system, so you don't create duplicates.
• Treat Purge and hard delete as permanent. Delete moves records to the Recycle Bin. Purge removes them. Don't purge unless someone with authority has signed off.
• Check the Excel trap. Spreadsheets quietly strip leading zeros, reformat dates and truncate long IDs. Save as CSV and open the file in a plain text editor before uploading.

My take: The risk in Workbench isn't the tool, it's the one-person, no-review workflow around it. If a change touches more than a few hundred production records, a second person should read the CSV and the query before you click Confirm. It takes ten minutes and it's cheaper than any recovery.

How to retrieve and deploy metadata

Use the Migration menu to retrieve metadata with a package.xml and deploy it as a zip, but use the Salesforce CLI if you're doing this regularly.

Workbench connects to the Metadata API. To retrieve, go to Migration > Retrieve, supply a package.xml (or pick components), download the zip and unpack it. To deploy, go to Migration > Deploy, upload the zip, and set the options such as check-only and tests to run.

A minimal package.xml to pull all custom objects:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
 <types>
 <members>*</members>
 <name>CustomObject</name>
 </types>
 <version>62.0</version>
</Package>

Use a version number your org supports. Always run a check-only deploy first. For anything you do repeatedly, the Salesforce CLI with source control gives you history and repeatability, which Workbench doesn't.

Salesforce Workbench vs Data Loader, Developer Console and CLI

Pick the tool by how often and how big the job is, not by habit.

Task	Workbench	Better choice when
Quick SOQL check	Good	Developer Console works too
Find deleted records	Good (include deleted option)	Recycle Bin in the UI for a few records
Load 100,000+ records on a schedule	Poor	Data Loader or an integration tool
Explore REST or SOAP calls	Good	Postman or CLI for repeatable tests
Move metadata between orgs	Possible	Salesforce CLI with version control

If you want a deeper comparison, see Salesforce Workbench: safe use and better alternatives.

What are the most common Salesforce Workbench mistakes?

The same five mistakes cause most of the damage, and all of them are avoidable.

• Logging in to production when you meant the sandbox.
• Running an update with no backup export.
• Forgetting that flows and triggers fire on API changes.
• Using a spreadsheet that corrupted the IDs or dates.
• Leaving the session open on a shared computer.

My take: In an AI-agent world these rules matter more, not less. Agents will call Salesforce APIs the way Workbench does: fast, literal and without hesitation. If your team can't run a careful Workbench update, it isn't ready to give an agent write access. I'd start any agent with read-only access, the same way I'd start a new admin.

Try this week:

• Open a sandbox and run the three queries above, then export one object as a Bulk CSV.
• Write a one-page "before any bulk update" checklist: sandbox test, backup export, five-record trial, second reviewer.
• Check which users have API Enabled and Modify All Data, and trim anything unnecessary.
• Practise a check-only metadata deploy from Workbench or the CLI.

If you want help setting data-change rules for your team, get in touch.

Frequently asked questions

Is Salesforce Workbench safe to use?

Yes, if you treat it with care. It uses OAuth and respects your permissions, but it has no undo, so safety comes from your process: sandbox first, small batch, backup export, review. Log out when you finish.

Is Salesforce Workbench an official Salesforce product?

It's hosted on a developerforce.com address and widely used. Don't expect Salesforce Support to fix it the way they would a core feature.

Can I use Workbench with a sandbox?

Yes. Choose Sandbox on the login screen and log in with your sandbox username. Always confirm the org name in the top bar before you run anything.

Can I recover deleted records with Workbench?

You can query deleted records by enabling the option to include deleted and archived records, and you can use Undelete on records still in the Recycle Bin. Once purged or past the retention period, they're gone, so confirm the current retention in Salesforce's help.

What's the difference between Workbench and Data Loader?

Data Loader is a supported desktop client built for large, repeatable data loads and can be scripted. Workbench runs in the browser and suits quick queries, inspection and one-off changes.