In a spreadsheet-style grid
Records in a table, edited cell by cell, a value copied down a column, and actions run on the selected rows - without leaving the CRM.
Clean
One standard, every record
Country arrives as "USA", "U.S.A." and "United States". Configure the correction once, run it across every record that matches, and the same action keeps running on new and updated records. No export, no spreadsheet.
What changes when one field is wrong everywhere
Before Plauti
- Export to a spreadsheet, fix the values, import them back.
- A list view lets you act on a few hundred records at a time.
- Whoever needs a bulk change files a ticket and waits for an admin.
- The next import brings the old spellings straight back.
WithPlauti
- The correction runs on the records in place, inside the CRM.
- A filter defines the set, and the job batches through all of it.
- Approved actions sit with the team that owns the data, capped at how many records one run can touch.
- The same action runs on a schedule, or the moment a record is created or updated.
What a field correction can actually do
A correction is a configured action: which records it targets, which fields it writes, and what it writes into them.
Replace a value everywhere it appears
Match an exact string or a pattern, on the whole field or part of it, and replace it. Several rules can run in one pass.
Write one or more fields at once
Set a value across the whole set, or populate a field from a related record.
Turn free text into a controlled value
Send a field to a language model with your own prompt and write the answer back. Your provider, your model, your key.
Reassign, aggregate, re-parent, convert
Ownership distributed evenly or by weight, values aggregated from related records, company hierarchies rebuilt, prospect records converted - in bulk.
Run your own logic across the whole set
Automation you already built, or custom code for what the built-ins miss, exposed as an action.
No list of records to select.
A filter defines the set instead of a list view, so a run is not capped at the few hundred records a list view allows. The job executes in the background in batches that stay inside the platform's own processing limits, and reports progress, results and per-record errors in one overview. There is no hard ceiling on records per job beyond what your subscription defines.
The same action, four ways to start it.
Run it by hand on a set of records from a list view or a report. Save it as a macro so the next person runs the same configuration instead of rebuilding it. Put it on a schedule - nightly, weekly, monthly. Or attach it to record events, so it evaluates each record as it is created or updated and only touches the ones that match.
Where the correction runs
From a list view or a report
Select the records, pick an action or a saved macro, set the parameters, review, run.
As a background job
A filter, an action, and a run that batches through the whole matching set instead of a screenful of it.
On a schedule
The same job or macro, nightly, weekly or monthly, with its history and errors in the same overview as a manual run.
The moment a record changes
Record events start the action per record, so values are standardized as data arrives instead of at the next cleanup.
Does it work the way you need it to?
The four things admins check before a bulk-change tool goes near production.
Who can run what, and how much
Access is granted per action, per user or role, and per object. A cap on records per run limits how much a single mistake can reach.
- Lower caps for newer users, higher for specialists
- Sensitive actions reserved to a small group
- Field and record access still comes from your existing permissions and sharing rules
Every run leaves a trail
Two logs: one for the run, one for the records. The record log keeps the value before and the value after, field by field.
- Which action ran, when, and who started it
- Filter by user, action or time period
- Purge old entries on your own retention policy
It holds at your volume
Jobs run in the background in batches that stay inside the platform's processing limits, with no hard record ceiling beyond your subscription.
- Filter-based selection instead of list-view selection
- Progress, results and per-record errors in one overview
- Try it on a subset before the full run
It fits the automation you already have
Actions run inside your CRM's own save sequence, not around it, so the rules you already rely on still decide what is allowed.
- Automation you already built, run in bulk as an action
- Custom code exposed as an action for what the built-ins miss
- Field changes can be reversed selectively afterwards
Features
Deduplicate CRM records
Plauti SDK
Monitor data quality in real-time
Integrate with your existing CRM
Automate data maintenance
Enrich records with verified data
Analyse and report on data health
Manage the full data lifecycle
Detect and prevent data decay
Take action on data insights
Customer quote
Bulk data changes
"46.7% of Salesforce admins still use spreadsheets to cleanse and transform CRM data, and **48.6%** name the risk of manual error as their biggest problem with doing it that way."
Salesforce Ben Admin Survey 2026
SalesforceBen
Frequently asked questions
Can I see what will change before it runs?
Yes. You filter the target records, see which ones are in scope, and review the configured change before executing it, and you can run it in manageable batches. Field-level changes can also be reversed selectively afterwards.
Does it respect our permissions and validation rules?
Yes. Object and field-level security, sharing rules, validation rules and existing automation all still apply, because the action runs inside your CRM's normal save sequence. Users can only change fields and records they already have access to.
How many records can one run touch?
A job is not tied to list-view selection, so it is not capped at the few hundred records a list view allows. There is no hard record ceiling beyond what your subscription defines, and batching keeps each run inside the platform's processing limits.
Which fields cannot be updated?
Read-only fields. Calculated fields, aggregate fields and auto-generated numbers cannot be written by any tool, including this one.
How is this different from a data loader or a script?
The work stays inside the CRM, so there is no export and re-import, and the same security, validation and automation apply as to any other save. Actions are saved and documented in one library instead of living in someone's local script, and every run is logged.
Can we hand this to the team that owns the data?
Yes, under admin control. You choose which actions and macros each user or role can run, on which objects, and how many records they can change per run.
See how it works
Talk with one of our experts to see how that works for your use case.