Clean up CRM data before automating follow-up

Write the conditions that make a record eligible for the intended action. Depending on the process, those may include a confirmed account relationship, an assigned owner, a usable contact field, a relevant lifecycle stage, and the absence of a current contact restriction.

Do not infer permission to contact someone from a populated email field. Preserve the business's existing contact rules and restriction fields, and route uncertainty for review. This article is about operational data preparation, not legal advice or a replacement for the organization's approved communication policies.

Examine how the CRM identifies contacts and companies. Duplicate checks differ by system and by the way records enter it. Microsoft's duplicate-detection documentation describes rules and matching criteria for its model-driven and customer-engagement apps. Those product-specific rules are not evidence that every CRM behaves identically or that all duplicates are prevented.

Confirm the matching method in the system actually being used. Keep a stable record identifier in the workflow rather than relying only on a displayed name. Before merging records, review conflicting ownership, activity history, contact restrictions, and open work. A duplicate label does not establish which record should survive.

A spreadsheet, CRM, and recent conversation may contain different information. Set a field-level rule where practical: the account owner might confirm a destination, while an approved product record determines a product description. Preserve the source and review history when correcting information.

Do not ask a generative assistant to invent a missing job title, company relationship, or buying interest to fill a template. A missing field should lead to an explicit omission, a suitable unpersonalized draft, or a pause, depending on the agreed workflow. A polished guess is still a guess.

Illustrative example: A fictional distributor finds two contact records sharing an email address. One is assigned to an account owner; the other contains a recent note and a different contact restriction. The cleanup task sends both records to the owner for review. The follow-up task waits rather than merging the records and sending immediately.

This separation makes it possible to review the data change before it drives an external action. It is an illustrative design scenario, not a report of customer performance. The decision packet should explain the conflict and retain links to both records so the owner can inspect the evidence.

Try records with no owner, an old destination, conflicting stages, a duplicate identity, and an existing follow-up already in progress. Confirm that an ineligible record stays out of the sending path and that the operator can see why it was excluded.

Also test a record that becomes restricted after a draft is prepared. Decide when the workflow rechecks eligibility before any send. The correct point depends on the process, but a draft should not become permanent authorization to contact someone after the underlying conditions change.

Give each unresolved record a reason, an owner, and a next action. Avoid a generic bad-data bucket that requires every reviewer to rediscover the problem. Distinguish a correction awaiting approval from a record already corrected and ready for a new eligibility check.

Start with the fields required by the bounded workflow and maintain those checks as the process evolves. Workflow status explains how to separate preparation from completed action, while my approach and the brand portfolio give wider context for connected systems. The Wolf Pack CEO assessment linked below can structure the initial discussion; it does not replace reviewing the CRM's actual records and rules.

Microsoft Power Platform: Set up duplicate detection rules to keep your data clean — Product-specific rules define record types, matching criteria and blank-value handling, and require publication to become usable. Not evidence that all CRMs behave identically or prevent every duplicate.