Salesforce Workbench: Safe Use and Better Alternatives

Salesforce Workbench can update 50,000 records in the time it takes to make tea, and it will do the same to the wrong 50,000 just as fast.

That's why this guide exists. If you query, update or inspect data and metadata for a living, you'll meet salesforce workbench sooner or later. Here's what it does, how to use it without hurting your org, and when another tool is the better choice.

Key takeaways

• Salesforce Workbench is a browser-based tool that talks to your org through Salesforce APIs, and it's excellent for looking at data and metadata.
• Treat it as a read tool first: query freely, but write only with a saved backup file, a sandbox test and a five-row trial.
• For repeatable or scheduled loads, use Data Loader or the Salesforce CLI. For quick browser lookups, use Salesforce Inspector.
• Workbench can be installed and hosted yourself as well as used from the shared copy, so decide deliberately which to use.

What is Salesforce Workbench and what does it do?

Salesforce Workbench is a web-based suite that lets admins and developers describe, query, change and migrate data and metadata in an org through the Salesforce APIs.

The project's own GitHub wiki describes support for the Partner, Bulk, REST, Streaming, Metadata and Apex APIs. The wiki's home page was last edited on 26 October 2020, which tells you something: this is a stable, mature tool, not one with a fast roadmap.

In practice, these are the parts I'd actually use:

• Queries: run SOQL and SOSL, and see results as a table you can export.
• Data: insert, update, upsert, delete and undelete from a CSV file.
• Info: describe objects and fields, including ones the Setup UI makes tedious to browse.
• Utilities: a REST Explorer, Apex execution and a few admin helpers.
• Migration: retrieve and deploy metadata.

Its real strength is reach. It supports the Partner, Bulk, Rest, Streaming, Metadata and Apex APIs directly in the browser.

My take: Workbench is the best free magnifying glass in the Salesforce ecosystem and a mediocre toolbox. Use it to look. Be slow to let it write.

How do you log in to Salesforce Workbench?

You log in with your normal Salesforce credentials through OAuth, choosing Production or Sandbox and an API version, and you should know exactly what access you're granting.

1. Open Workbench (the shared copy has long lived at workbench.developerforce.com) and choose Production or Sandbox.
2. Pick an API version. For queries, the newest your org supports is fine.
3. Accept the terms and choose Login with Salesforce, then approve the OAuth request.

If login fails, check your org's connected app policy. Many orgs restrict which connected apps users can authorise, and an admin may need to approve the app. You can review and revoke what you've granted under Setup > Connected Apps OAuth Usage.

One decision matters more than the rest. An OAuth token is a real credential, so know what access you're granting. Some teams prefer to host their own copy from the open-source code, so they control the host. For a regulated org, that choice belongs with your security lead, not with whoever found the tool first.

How do you run safe SOQL queries in Workbench?

Query before you change anything: count the rows, inspect a sample, and keep the result as your backup.

Go to Queries > SOQL Query, pick the object, and either use the field picker or type the query. The SOQL reference covers the syntax. These patterns cover most of my day-to-day use:

-- Count first. How big is the blast radius?
SELECT COUNT() FROM Opportunity
WHERE IsClosed = false AND CloseDate < LAST_N_DAYS:365

-- Then look at a sample, with the Id you'll need later
SELECT Id, Name, StageName, CloseDate, OwnerId
FROM Opportunity
WHERE IsClosed = false AND CloseDate < LAST_N_DAYS:365
ORDER BY CloseDate
LIMIT 200

-- Find likely duplicate contacts
SELECT Email, COUNT(Id)
FROM Contact
WHERE Email != null
GROUP BY Email
HAVING COUNT(Id) > 1

-- Parent with children in one result
SELECT Id, Name, (SELECT LastName, Email FROM Contacts)
FROM Account
WHERE Id = '001XXXXXXXXXXXXXXX'

Before you press Query, check that every filter is something you'd defend. A missing WHERE clause on a big object is how people lock up an afternoon.

How do you update records in Workbench without breaking things?

Match on record Id, test in a sandbox, run five rows first, and always keep the original values in a file.

Here's the routine I'd follow.

1. Export the target rows with their Ids. Run the query above and save the CSV. This is your rollback file, so don't edit it.
2. Build a separate update file. Make a copy containing Id plus only the columns you're changing. For example, a services company might reassign stale opportunities by setting OwnerId to a queue owner.
3. Rehearse in a sandbox. A full or partial copy gives the most realistic result.
4. Check what fires. Updates trigger validation rules, flows, Apex triggers and assignment logic. Know the sequence in the order of execution before you touch 10,000 rows.
5. Load five rows. Go to Data > Update, choose the object, upload the file, map the columns and confirm. Check those five records in the UI.
6. Run the rest. For larger files, choose the Bulk API option on the confirm screen. The Bulk API 2.0 documentation explains how batches are processed.
7. Read the results. Download the success and error files and reconcile the counts against your input. Don't trust "it finished".

Workbench never asks "are you sure this is the right 50,000?", so the discipline has to come from you. Use the same rule I'd give anyone starting with an AI agent: read-only first, a human approving, and promotion only after it earns it. Powerful access should be earned in steps, whether it belongs to a person, a script or an agent.

My take: The biggest risk with Workbench isn't a bug. It's that a successful run looks identical to a disaster. Only your backup file tells them apart.

Salesforce Workbench vs Inspector, Data Loader and the CLI: which should you use?

Use Workbench to inspect and for one-off jobs, Salesforce Inspector for fast lookups, and Data Loader or the CLI for anything you'll repeat, schedule or have to audit.

Tool	Best for	Repeatable or scheduled	Watch out for
Workbench	Deep inspection, deleted records, REST calls, one-off loads	No built-in scheduling	Unsupported open-source project; OAuth to a third-party host
Salesforce Inspector (browser extension)	Quick queries and field lookups beside the record you're on	No	Community-built; install and permissions are your call
Data Loader	Large imports and exports from a desktop	Yes, via its command-line mode	Needs a local install
Salesforce CLI	Scripted, version-controlled data and metadata work	Yes, in scripts and pipelines	Learning curve
Developer Console Query Editor	Quick SOQL with no setup	No	Basic export and display

A few specifics on how I'd choose:

• Data Loader is Salesforce's own tool for importing and exporting large volumes, and it keeps success and error files by design. It's my default for any load someone will ask about again in six months.
• The CLI wins when a job must run the same way every time. Commands such as sf data query and sf data update bulk can sit in a script that lives in source control, so the "what did we run?" question has an answer. See the CLI reference for the exact commands in your version.
• Salesforce Inspector is a community browser extension, so I'd treat it like any extension: review its permissions and use it where your policy allows.

My take: If you're running the same Workbench update twice, you've already made a mistake. The second run belongs in a script or Data Loader job with a saved log.

What are the most common Salesforce Workbench mistakes?

Most Workbench damage comes from the same five habits: no backup, wrong org, name matching, ignored automation and skipped error files.

• Running against Production when you meant Sandbox. Check the org name on the screen before every write. Colour your sandbox browser profile differently.
• No backup file. Without the original values, "undo" means an expensive data recovery request.
• Matching on name. Names repeat. Use Id, or a unique external Id with upsert.
• Forgetting automation. A flow that emails customers will happily email 10,000 of them from a bulk update.
• Skipping the error file. A 98% success rate means 2% of your data is now inconsistent.

There's a governance point behind all of this. A tool with this much reach should have named owners, a sandbox-first rule and a short written procedure for production changes. If your team learns those habits on Workbench, they'll apply them to everything else. If you're building that foundation, the Admin interview questions guide shows what good admins are expected to know about data changes. For a proper review of how your org handles data operations, you can get in touch.

Try this week:

• Open Workbench in a sandbox and run the four example queries against your own data.
• Write a one-page "production data change" procedure: backup, sandbox, five-row test, results check.
• Install Data Loader and run one export, so it's ready before you need it.
• Check Connected Apps OAuth Usage in Setup and revoke tokens for tools nobody uses.

Frequently asked questions

What is Salesforce Workbench used for?

It's used to query data with SOQL and SOSL, insert, update, upsert and delete records from CSV files, describe objects and fields, call REST endpoints and retrieve or deploy metadata. Admins also use it to see deleted and archived records. It works through Salesforce APIs from a browser.

Is Salesforce Workbench safe to use?

It's safe when you use it with discipline: sandbox first, a backup file, a small test batch and a check of the results. Review who hosts it and what OAuth access you're granting. Regulated teams often host their own copy.

Is Salesforce Workbench still available and worth using?

Yes, the open-source project is still around and many admins still use it for inspection. It's less suited to scheduled or audited jobs, where Data Loader or the Salesforce CLI are better. Check that your org's connected app policy allows it.

What is the difference between Workbench and Data Loader?

Workbench runs in a browser and is flexible for inspection, deleted records and API calls. Data Loader is Salesforce's own desktop tool for large imports and exports, with a command-line mode for repeat jobs. Choose Data Loader when you need a repeatable, logged load.

What can I use instead of Salesforce Workbench?

Salesforce Inspector for quick browser lookups, Data Loader for large data loads, the Salesforce CLI for scripted work and the Developer Console Query Editor for simple SOQL. Most teams keep two of these and use each for what it does best.