Inline edit from a list view for a handful of records. Data Loader with an export-edit-update cycle for anything larger. A Flow when the change is rule-based and will need to happen again. Apex only when the logic cannot be expressed any other way. Whichever you pick, export the current values first, because there is no undo.
| Method | Scale | Use when | Watch out for |
|---|---|---|---|
| Inline edit in a list view | Up to ~200 | A quick, visible change on records you can see | No log beyond field history, and easy to mis-click |
| Data Loader update | Millions | Export, edit in a spreadsheet, update by record ID | Updates exactly what you send, including the mistakes |
| Flow | Any | The rule will apply again, or should run on a schedule | Bulk-safe design, and it fires on every row you load |
| Apex | Any | Logic no declarative tool can express | Needs a developer, tests, and someone to own it afterwards |
The pre-flight checklist
- Export the records and the fields you are about to change, with IDs. This is your only rollback.
- Count the records your filter returns and confirm the number against expectation before you touch anything.
- Check what automation will fire: Flows, validation rules, assignment rules, roll-up summaries and outbound integrations.
- Run it in a sandbox with the same volume.
- Update a batch of twenty in production, verify, then run the rest.
- Verify afterwards by field comparison against your export, not by record count.
The failure mode that hurts
The damaging bulk updates are rarely wrong in an obvious way. They are right for most records and wrong for a subset nobody thought about: the closed matters, the inactive households, the records owned by a departed advisor. Because the change succeeds, nothing alerts, and the error surfaces weeks later inside a report.
That is why the export in step one exists, and why verification is a field comparison rather than a row count.
Why this keeps coming back
Mass updates are triggered by ordinary events: a practice-group reorganization, an advisor departure, a fee schedule change, a rebrand, a merger, a new required field applied retroactively. They are not exceptional; they are quarterly. Treating each one as a one-off manual project is what makes them expensive.
Where Caddi fits
Caddi runs the recurring ones. Record the update once, including how you decide which records are in scope, and it runs as deterministic code with the export, the batching and the verification built into the run. You get a report of exactly what changed on which records, which is both the safety net and the audit trail.
Related: Duplicate management, Import Wizard vs Data Loader, and CRM data hygiene.
The recurring half
See a bulk update run with a verification report
Caddi exports, batches, updates and verifies, and hands back exactly what changed.
Frequently asked questions
How do I mass update records in Salesforce?
Inline edit from a list view for small numbers, Data Loader with an export-edit-update cycle for larger sets, a Flow when the change is rule-based and recurring, and Apex only when nothing else can express the logic. Export the current values first in every case.
Can you undo a mass update in Salesforce?
Not in general. Field history tracking helps on tracked fields, and the recycle bin covers deletions rather than updates. The reliable rollback is the export you take before the change, which is why it is step one.
How many records can you mass edit in a Salesforce list view?
List view inline editing is practical for up to a couple of hundred records and depends on the list view configuration. Beyond that, use Data Loader or a Flow.
Do Flows fire during a Data Loader update?
Yes, once per record, unless you deactivate them for the load. Decide that deliberately, because leaving them active can trigger thousands of downstream actions and disabling them can skip logic the records need.