← All tools

Mass Update / Delete

Mass update or delete Salesforce and HubSpot records from one filter

Apply a change across a filtered population, as one instruction with one audit trail.

SalesforceHubSpotReversible

A change that belongs to thousands of records. The rename, the re-tag, the correction after a bad import. It is one decision and ten thousand edits, so it becomes an afternoon of spreadsheet work that nobody can review and nobody can undo.

Mass Update is the tool with no saved rules, and that is deliberate: the instruction is the run. Which fields, and what each one should become.

The scope is the careful part. A filter over your own fields, built the same way every other tool builds one, with a count you can read before you commit to anything.

Delete is the same tool. Removing records that should not be there is the same shape of operation as correcting them, held to the same review and the same trail.

How a pass runs

From scope to record.

  1. Scope. A filter over your own fields, with a live count of how many records it selects.
  2. Instruct. The fields to change and the value each should take.
  3. Review. The run can be held for approval, so the count and the instruction are both read by a person before anything moves.
  4. Write changed only. A record already holding the target value is skipped.
  5. Record. Every write is stored with the value before and the value after.

The detail

What it needs and what it does.

Object
Accounts, contacts and leads.
Configured in
Nothing to configure. The run carries its own instruction.
What it writes
The fields you name, across the records your filter selects.
Who releases it
You choose when you create the run: write on dispatch, hold the whole run for approval, or queue one proposal per record.
Reversible
Yes. Every write is stored with its prior value and the whole run can be put back.
CRMs
Salesforce and HubSpot.

The count

The number is the safety mechanism.

A bulk edit goes wrong at the filter, not at the write.

Nobody sets out to update forty thousand records. They set out to update the four hundred in one region and write a filter that does not say what they think it says. By the time the mistake is visible it is already everywhere.

So the count is shown against the real scope before the run is created, the run can be held for a second person to read, and if it still goes wrong the whole run reverses as a unit rather than record by record.

For agents

The tools your agent calls.

Reads are free and need no permission to write. Anything that changes a record is a separate grant.

count_crm_records how many your filter actually selects read
list_filterable_fields the fields and operators your CRM offers read
create_mass_update_run a run with a scope and an instruction write
dispatch_run start it write

Where to start

Find out how many you have.

The readiness scan runs detection against your own CRM and reports what it finds, before anything is merged.