Mass Update / Delete
Apply a change across a filtered population, as one instruction with one audit trail.
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
The detail
The count
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
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 readlist_filterable_fields the fields and operators your CRM offers readcreate_mass_update_run a run with a scope and an instruction writedispatch_run start it writeWhere to start
The readiness scan runs detection against your own CRM and reports what it finds, before anything is merged.