CRM data management starts with clear identity decisions, field ownership and retention decisions. Review possible duplicates before merging, define who may change each important field and test access with the intended user roles. Treat deletion as an approved records decision with clear consequences, rather than an automatic way to make the database look tidy.
Clean data is data that people can use and explain. A single customer record is not useful if it combines two different people, loses the reason a value changed or exposes information to the wrong role. Start with those failure cases before commissioning a broad clean-up.
The original review packet below uses fictional lead records to join duplicate handling, protected fields and retention ownership. Microsoft’s Dynamics 365 Sales and Dataverse documentation provide specific product examples. The packet proposes a review method; the organisation must supply its own approved retention decisions.
When is a possible duplicate actually the same person?
Dynamics 365 Sales requires an administrator to enable duplicate-lead detection. Check that prerequisite and the selected feature’s availability in the proposed installation. The duplicate-lead documentation describes candidate rules, but a candidate is still a record for review rather than a business instruction to combine every match.
Its duplicate-lead rules include a shared email address. Its duplicate-lead rules also include a shared phone number. A shared contact channel deserves investigation. A team inbox or reception number can appear on records for different people. Compare identity, context and related activity before deciding whether the records describe the same prospect.
Write a review outcome: same identity, separate identities or insufficient evidence. Keep the reason and reviewer with the decision. If the match is uncertain, route it to the data owner and avoid silently copying the newest-looking value over the others.
Dynamics 365 Sales lets a reviewer change the primary record during a lead merge. Inspect that choice deliberately. The primary record’s apparent completeness does not establish that all its values are correct. Decide which name, contact information and ownership details should survive using the supporting evidence, and identify conflicting fields before accepting the merge preview.
After a documented lead merge, Dynamics updates the primary record and deactivates the others. Check the related records in the test copy afterwards. Record which identity remains active and whether the expected activity follows it. Keep the observed result separate from a planned bulk clean-up so the organisation can review the behaviour before authorising wider changes.
Who should own and protect important fields?
Create a field dictionary with meaning, source, authorised editor and correction route. A customer’s preferred contact channel, account owner and review status can have different owners. Do not grant editing rights merely because a field appears on a screen the person uses.
Dataverse column-level security configurations apply organisation-wide to data-access requests. The Dataverse column-security guide describes access at a narrower level than the whole record. Column security profiles control read, create and update permissions separately. Specify the intended actions for each role; being able to see a value does not necessarily mean the person should be able to set or change it.
Dataverse column-level security does not hide data from system administrators. Microsoft requires a non-system-administrator account to verify column-security results. That condition is essential for a meaningful acceptance check. An administrator demonstrating a protected field has not established what an ordinary account can see. Use approved test identities representing the intended roles and retain separate observations.
Microsoft warns that calculated or prompt columns can expose data from secured source columns. Include derived views in the access review. A protected source field can still be a design problem if its value is exposed through another representation. Review the actual forms, reports and calculated results relevant to the proposed workflow instead of checking only the original input control.
| Data decision | Owner to appoint | Evidence required | Exception to preserve |
|---|---|---|---|
| Duplicate identity | Data steward | Compared records and matching context | Shared inbox with different people |
| Conflicting value | Named field owner | Approved source and correction reason | Two plausible but incompatible values |
| Restricted field | Information owner | Role-by-role read and update test | Derived view reveals a protected value |
| Retention outcome | Approved records-policy owner | Applicable policy decision and record scope | Unresolved dependency or approved hold |
| Bulk change | Authorised change owner | Tested method, backup and recovery plan | Partial completion or unexplained mismatch |
How should retention fit the data workflow?
Inventory what the CRM retains: contact fields, activities, attachments, imported files and linked records. Ask the organisation’s responsible owner to provide the approved treatment for each category. Do not substitute a software default or an arbitrary duration for that decision.
Separate correction, deactivation, restricted access and deletion. They answer different needs and can have different consequences for linked records. A duplicate-handling workflow should not become an unreviewed records-disposal policy. Keep the proposed outcome visible in the review packet and require the appropriate approval before activation.
Document dependencies before changing records. An attachment, transaction reference or unresolved service issue may need a particular treatment under the organisation’s policy. Record the decision and its scope, then test the supported process in an isolated copy using fictional or approved non-sensitive data.
Original duplicate-and-field review packet
Use a hypothetical pair of leads for “A. Phiri” and “Alice Phiri” sharing a general office email address, plus a third record for another person using the same reception number. These similarities deliberately create ambiguity. They are not evidence that any pair should be merged.
Identity sheet: Compare the fictional organisation, role, contact context and activity descriptions. Write a reasoned outcome for each candidate pair. The exercise succeeds when the reviewer can explain why two records are the same or different; a match alert alone is insufficient.
Survivor sheet: For a pair deliberately defined as the same fictional person, list the proposed primary record and each conflicting field. Record the source chosen for the retained value. Review the merge preview in the test copy and check active identity and activity links afterwards.
Field-access sheet: Add a fictional internal review note. Specify which test role may read it, which may update it and which should see no value. Test the ordinary form and relevant derived view using those non-administrative roles. Record both allowed and denied actions.
Retention sheet: List the surviving record, inactive duplicate, attachments and exported review file. For each, leave a field for the organisation’s approved policy decision, decision owner and activation authority. Do not fill an unknown period with a convenient guess.
Exception sheet: Introduce an unresolved identity and a failed change. Record who investigates, what remains unchanged and what evidence is needed to proceed. This makes the packet useful for normal uncertainty instead of encouraging staff to force every candidate into a merge.
What makes a clean-up ready for controlled execution?
Retain approved decisions, tested permissions, the change scope and recovery evidence before proposing a wider operation. Review the exceptions with the people who own the records. A tidy count is not the acceptance criterion; preserved identity, correct values and appropriate access are.
For broader scope, see business systems and web development. To discuss a CRM data brief, get started with a fictional review packet, your field dictionary and the retention decisions your organisation has already approved.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.