When Should Two Enquiries Count as One CRM Record?

Two enquiries should count as one CRM record when they clearly concern the same person or organisation and the same underlying request. If the identity or request is uncertain, keep them separate until someone can check. That simple rule helps avoid both clutter and the more serious mistake of losing a distinct enquiry inside the wrong record.

This matters when a person contacts a business through more than one route: they may submit a form, then call, or send a WhatsApp message after speaking to someone. A CRM needs to connect those interactions where appropriate, while preserving what was said and when.

Match the person and the request, not just one field

A shared email address can be a useful clue, but it is not always proof that two records belong together. People may use a work address for a colleague, share an inbox, or contact a business on behalf of someone else. Phone numbers can also be entered in different formats or belong to a household or company.

A practical review asks two questions:

• Is this the same contact or organisation? Compare more than one detail where possible, such as name, email, phone number and company.
• Is this the same request? Check the subject, service needed, location, timing and any earlier conversation.

If both answers are likely yes, link the new interaction to the existing record. If it is the same person but a genuinely new job or requirement, keep the contact details connected but create a separate enquiry or opportunity. If identity is unclear, flag it for review rather than merging automatically.

Set rules around the cost of getting it wrong

A duplicate enquiry can waste time: two people may follow up separately, or reports may count one prospect twice. But an incorrect merge can hide an urgent or unrelated request. Decide which error is more disruptive for each stage of your process.

For example, it may be reasonable to flag a likely repeat for a quick human check when an enquiry first arrives. Automatically merging records deserves a higher confidence threshold, particularly if it could overwrite notes, ownership or follow-up dates. Keep a way to undo a merge or restore the original details if the CRM supports it.

Microsoft’s documentation describes Dataverse as storing business application data in tables, with records made up of fields. That structure is useful when deciding which fields can support a match and which information needs to remain distinct (Microsoft: What is Dataverse?). The exact setup and behaviour depend on the CRM being used; Dataverse documentation should not be assumed to describe every CRM.

A checklist for a sensible duplicate policy

Before enabling matching or asking staff to merge records, agree on:

• Fields to compare: Which details are reliable enough to suggest a match? Can a phone number or email be shared?
• What counts as a repeat: Is this a new message about an open enquiry, a reopened request, or a separate piece of work?
• What to preserve: Keep original message dates, channel, notes, owner and next action visible after linking records.
• When a person must check: Send uncertain matches to a review queue instead of silently combining them.
• How to correct mistakes: Decide who can unmerge or repair records and how the team records the correction.
• How to test the rule: Try known examples, including contacts with the same name, shared email addresses, changed phone numbers and repeat enquiries about different work.

Hypothetical example

A property maintenance firm receives a web form from Alex, then a WhatsApp message from a number with a different name asking about the same address. The address and issue appear to match, but the sender could be a tenant, owner or another household member. A cautious process flags the records for a quick check. If staff confirm it is the same repair request, they link the message to that enquiry while retaining who sent it. If it concerns a separate issue, it remains a separate enquiry.

What automated duplicate detection can and cannot do

Microsoft says its Power Apps duplicate detection uses published rules to compare match codes, and describes matching fields such as email address, first name and last name. Its documentation also notes limitations: records created at almost exactly the same time can both be added, so scheduled checks may still be useful. It lists situations where detection does not run, including some record status changes. These details apply to the documented Power Apps and customer engagement scenarios, not automatically to other systems (Microsoft: Detect duplicate data).

So treat automated matching as a way to surface possible duplicates, not as a substitute for a clear policy. Review a sample of flagged and missed cases after launch, then adjust the rule when real enquiry patterns show where it is too strict or too loose.

Should every repeated message be merged? No. Link it to the original enquiry if it is the same request; preserve a separate record if it is different work or the identity is uncertain.

Where can I start? Map how enquiries enter your CRM and decide what should happen when the same person contacts you twice. For help connecting enquiry handling with CRM follow-up, see the CRM Pipeline Watchdog.