A CRM data quality checklist for records that need a decision

Updated 9 November 2026 · By ApprovalCRM

A useful CRM data quality checklist separates a known correction from an unresolved decision. Define the fields that matter, preserve the source and original meaning, identify missing or conflicting values, and assign someone to review exceptions. Do this before treating a cleaned-looking spreadsheet as a trustworthy customer record.

Fourteen relevant discussions informed this guide. People described stale fields, incomplete records, uncertain matches, inconsistent entry and missing context. Some discussed planning or concerns about AI-generated updates. Those needs do not prove a particular model failure, a universal cleanup method or that automated enrichment will make a record accurate.

Define the record and each important field

Start with the job the record supports. Our fictional example tracks organizations with an assigned owner, a next step and a source note. It does not contain real customers or personal-profile information. The field definitions are author-proposed for the example, not a standard that every CRM must adopt.

For each field, write its meaning, who may change it and what an empty value means. Unknown is different from not applicable or not yet reviewed. If you use a placeholder simply to pass a required-field check, make that limitation visible rather than treating the placeholder as verified information.

Our record quality worksheet includes columns for the field, observed issue, original value, proposed correction, source, responsible person and decision. Adapt it to the authorized records your team already holds. It is not a recipe for buying lists or collecting additional personal profiles.

Keep the source and the original meaning

Before changing a value, record why the change is proposed. A source note, a confirmed correction and an inferred suggestion are different kinds of support. Keep enough context for the reviewer to understand that difference without turning every tentative statement into a completed commitment.

For an invented example, the note says, “Possible next phase after review.” Our proposed update preserves that condition and leaves the decision pending. It does not create an agreed start date. The example illustrates a desired handling rule; it is not a test of a language model or evidence about any vendor's output.

If a draft changes the meaning, ask the responsible person to review the original context before accepting it. Human review is still a task that can be incomplete or mistaken. This checklist does not guarantee accuracy simply because a review field exists.

Treat possible duplicates as a review question

A shared value can be a reason to inspect two records, without being enough to merge them. Decide what evidence your team requires for a match and what should happen when the evidence conflicts. Keep both original records while that decision is unresolved.

Our synthetic CSV contains two rows with the same fictional account reference but different status and owner fields. A local script flags the repeated reference and writes both rows to a review list. It does not merge them, delete a row, decide which owner is correct or verify a real identity.

The example records and review output make that narrow test inspectable. A repeated reference is the rule we chose for this demonstration. It is not a sufficient matching rule for every CRM dataset, and the script does not establish a vendor's duplicate-handling behavior.

Route missing values to a person

Decide who handles an exception when a required piece of context is absent. In our example, one row has no next-step owner. The script flags it for assignment rather than inventing an owner or advancing the record. A person still needs to investigate and decide what should happen.

Record a responsible role and a review state for each issue. If no one is assigned, keep the issue open. Our recommendation is to make that gap explicit instead of sending the record to an unowned queue and assuming it has been handled.

Keep routine corrections and ambiguous changes separate. A spelling correction confirmed by the record owner is different from deciding that two accounts are the same or that a tentative conversation authorizes a new action. The worksheet helps describe that distinction; it does not enforce permissions in a live system.

Review the correction before applying it widely

Try a proposed cleanup rule on a small authorized sample and inspect the output before applying it more broadly. Preserve the source data and define how the team would recover from a mistaken change. This is a planning recommendation, not a claim that every product supports the same backup or rollback controls.

Ask your provider how imports, matches, permissions and history behave in your exact configuration. We read current primary documentation while preparing this guide, but did not test a provider account. Our local CSV check cannot establish a live system's import behavior, recovery capability or security.

Keep a correction owner after the first cleanup

Record who will notice new problems and who can resolve them. Revisit field definitions when the underlying workflow changes. A one-time tidy-up does not answer who maintains the record next week or how a disagreement will be handled.

If the team still needs a system, use the CRM selection trial. If the record will trigger changes elsewhere, define the update and handoff rules before automating them. These are connected jobs, without being evidence that every team needs an AI approval product.