A Salesforce Data Quality Playbook for Admins

Data quality is a loop, not a project

Every org gets a cleanup project eventually. Six months later the same duplicates are back, because a project fixes the data and a loop fixes the intake.

The loop has three steps, and each one is a query you can schedule into your own calendar: audit what is wrong, fix the current backlog, prevent the next batch. This playbook is the version we run, with the SOQL for each step.

Note:

Every query below uses standard fields only, so it runs as-is. Swap the object API name to point it at a custom object.

Step 1: audit — size the problem before touching it

Resist the urge to open a record and start editing. Count first. A number tells you whether this is an afternoon of cleanup or a conversation with whoever owns the integration.

-- How many contacts have no email at all?
SELECT COUNT()
FROM Contact
WHERE Email = NULL

Run the same shape across the four failure modes that account for most bad Salesforce data:

Failure mode	What to query
Missing values	`WHERE Field = NULL` on the fields your reports depend on
Duplicates	`GROUP BY` the natural key `HAVING COUNT(Id) > 1`
Stale records	`WHERE LastModifiedDate < LAST_N_DAYS:365`
Orphaned ownership	`WHERE Owner.IsActive = false`

The duplicate query is the one worth memorising, because the syntax is unlike anything else in SOQL:

SELECT Email, COUNT(Id) total
FROM Contact
GROUP BY Email
HAVING COUNT(Id) > 1
ORDER BY COUNT(Id) DESC

Aggregate queries do not return record IDs, so this tells you which values collide, not which records. Pulling the records is a second query against a value from the first — the duplicate contact walkthrough covers both halves.

Step 2: fix — export, edit, re-import, verify

The fix is mechanical, and the discipline is entirely in the order of operations.

Export the current values first

Include Id and every field you are about to change. That file is your rollback; there is no undo in Salesforce.

Check what the update will trigger

Validation rules that reject rows mid-batch, flows that cascade onto other objects, roll-up summaries that recalculate on the parent. A 10,000-row update is rarely just 10,000 rows of work.

Run ten records, then the rest

Inspect the first ten in the UI before you trust the mapping. Most bad imports are bad mappings, and they are obvious at ten rows and invisible at ten thousand.

Re-run the audit query

It should return zero, or the remainder you expected. If it does not, stop before the next batch.

The full procedure, including the automation traps, is in How to Mass Update Salesforce Records Safely.

Step 3: prevent — close the intake

Cleanup without prevention buys you about a quarter. The controls that actually hold:

Duplicate and matching rules on the objects with a natural key. Fuzzy matching at save time catches what an exact-match query never will.
Required at the layer that matters. A field required on the page layout is not required for the API, and integrations bypass layouts entirely. Use validation rules for anything an integration writes.
Own the integrations. Most recurring data quality problems are one integration writing what nobody reviewed. Find it by grouping today's edits by LastModifiedBy.Name.
Re-run the audit monthly. Fifteen minutes with the same four queries. The trend matters more than any single number.

-- Who or what changed contacts today?
SELECT LastModifiedBy.Name, COUNT(Id) total
FROM Contact
WHERE LastModifiedDate = TODAY
GROUP BY LastModifiedBy.Name
ORDER BY COUNT(Id) DESC

If an integration user is at the top of that list every day, your data quality work is upstream of Salesforce, not inside it.

The monthly fifteen minutes

Save four queries, run them on the first Monday of the month, and record the numbers in the same place each time:

Duplicate count on your two highest-volume objects.
Blank-field count on the three fields your executive dashboard depends on.
Records owned by inactive users.
Records not modified in twelve months.

Four numbers, trending. That is the whole programme — and it is the difference between a data quality project and a data quality practice.