Fix the records that stand between your team and a useful next step.

“Clean the CRM” can expand into an open-ended project. “Route a new request to the correct account owner without losing its buying-unit context” gives the review a purpose. List the fields needed for that decision before checking unrelated details.

For that request, the required information may be a stable account identifier, the buying unit, responsible owner, request status, latest relevant source and an unresolved question. A marketing description or complete address history may be unnecessary for routing, even if it is useful elsewhere.

Name the consequence of a wrong value. An incorrect industry tag may distort a segment; an incorrect account match may expose customer information or assign work to the wrong team. Prioritise defects according to the decision they affect, with the relevant access checks included.

Choose records from actual work you are authorised to inspect: a straightforward account, an existing customer, a new prospect, a parent with several branches, a recent import, a suspected duplicate and several records with missing or conflicting details. Overlap is fine; the aim is to expose different failure types.

For each required field, record confirmed, missing, conflicting or stale, with a source reference. “Confirmed” should mean someone checked an appropriate source, not merely that the database contains a value. Keep the date of that check and the person responsible for resolving an issue.

Use the sample to identify repair rules and test cases. Ten selected records cannot establish a dependable error rate for the whole CRM. If you need that estimate, design a separate sampling exercise; do not turn this diagnostic review into a quality score.

Keep the stable record ID alongside readable company names and domains. Confirm whether the workflow operates at group, legal entity, branch or buying-unit level. Two offices can share a website but require different owners and procurement decisions.

Check the actual creation and update path. HubSpot’s deduplication guidance notes that company records created through its API are not deduplicated by company domain. A manual import and an integration may therefore behave differently even when their source columns look alike.

Test name changes, shared domains and duplicate external records before relying on matching. Preserve an uncertain match for review instead of choosing the closest-looking name. The shared customer data guide sets out the broader identity and source model; this checklist checks whether records are ready for the specific workflow.

Finance may control billing details, sales may control the relationship owner and the customer may confirm a requested delivery date. Write that source priority per field. A generic “newest record wins” rule can replace an approved value with a recent but incomplete export.

Distinguish a blank value from an instruction to clear a field. A missing owner in an imported file should not erase the confirmed owner unless the agreed process explicitly authorises that change. Keep both conflicting values and their sources when no priority rule resolves the difference.

Add freshness only where the decision requires it. An old observation can be useful history while an old job title may be unsuitable for a current contact decision. The enrichment evaluation helps check new information against existing records instead of treating enrichment as automatic correction.

Before enabling broad updates, use a contained, authorised test set. Check a correct change, repeated input, older information arriving late, a missing value, a conflicting owner and an uncertain account match. Inspect the resulting destination record, not only the success message from the connection.

Record what happened if a write succeeded but its response was lost. Recovery should establish the existing state before trying again. Define whether the operator can reverse a change, restore a previous value or submit a correction, and keep the change history needed for that action.

The AI workflow testing checklist includes partial completion and access failures. These checks also matter for deterministic connections: a fixed rule can still update the wrong record if identity or source priority is wrong.

For every defect, record the affected decision, example record, expected rule, responsible owner and acceptance case. Group repeated defects under a rule where appropriate, while keeping the evidence that shows why the rule is needed. Avoid merging unrelated issues into a general “data cleanup” task.

Write the handover in the commercial workflow specification: which record is read, what may change, who reviews uncertainty and how the next person receives the result. Recheck the sample after repairs and add cases when a new failure type appears.

A separately scoped Plan can investigate account structure and source priorities and hand the findings to your team. Scope a data repair or connection around the decision it supports. When that work belongs in a Build campaign, name the records, acceptance checks and responsibilities in the campaign scope. Useful account work can proceed once its essential records are ready; unrelated fields can be addressed separately.