Customer Identity and MDM Operations First-Response Guide: Customer Profiles Merging Incorrectly During Account Link Because MDM Match Rules Lack Confidence Thresholds

What This Checklist Is For

When customer profiles start collapsing during account link, the MDM match rules are almost always the first place to look. This checklist gives your operations team a structured first-response sequence — run through these six steps before you page IT or open a vendor support ticket.

The pattern shows up in environments where your CRM, identity provider, storefront, and loyalty platform are writing into the same MDM layer independently. It also appears in loyalty platform integrations where a customer has both a rewards account and a guest checkout profile. Match thresholds that are set too low are the usual cause — the system merges records that share only a name or an email fragment, even when they represent different people.

By the end of this checklist, you will have the evidence you need for a clean escalation — or you will have ruled out the system handoff as the root cause entirely.

Step 1: Capture the Affected Records

Pull the two original profiles before you change anything. You need the one that existed before the link and the one that was merged in.

Export the following for each record:

• Customer ID
• Email address
• Phone number
• Full name fields (first, last, any middle or company name)
• Loyalty points balance and purchase history if applicable
• Account creation date and source system

The goal is to freeze the state. The merge event may have overwritten fields in the surviving record, and you need both profiles in full before any correction is applied.

Operator note: Merge events can carry forward loyalty history from the wrong record while dropping purchase history from the pre-existing profile. This asymmetry only becomes visible if you pull both records completely before correcting.

Step 2: Identify the Merge Trigger

Open the MDM audit log and locate the merge event timestamp. The log entry shows the match key that triggered the link — the specific field or combination of fields the system treated as a unique identifier.

Common merge triggers:

• Email address match — john.smith@gmail.com matched john.smith@gmail.com
• Phone number match where formatting differs between systems — (307) 555-0100 vs. 3075550100
• Name string match on an unformatted compound field — John Smith matched against JohnMichaelSmith from a bulk import
• Composite key match combining two or more low-specificity fields

This tells you which field the system treated as unique when it was not actually unique across two different people.

For more on why this distinction matters operationally, see Why Customer Identity Breaks When MDM Profiles Merge Incorrectly During Account Link.

Step 3: Verify the Match Rule Configuration

Open the MDM admin panel and locate the match rules governing account-link events. You need two pieces of information:

1. The confidence threshold controlling automatic merges
2. Whether the rule uses a single-field match or a multi-field composite with a secondary confirmation step

A single-field match with a low threshold is a frequent configuration error behind false merges. If the rule fires on email address alone — at anything under 100%, or at 100% on a field that has already been formatted differently across your CRM, identity provider, and storefront — it will false-positive.

Note the current threshold value and whether the rule is single-field or composite. These are the first things IT will ask for in an escalation.

Step 4: Cross-Check the Source Systems (CRM, Identity Provider, Storefront, Loyalty Platform)

Confirm whether both profiles originated from the same system or from different ones. This matters because cross-system merges carry higher false-positive risk.

Match rules written for a single-system environment — where your CRM is the only write into the MDM — often fail when a loyalty platform, a storefront, or an identity provider starts sending records with different formatting conventions. When you are working across multiple systems that each maintain their own customer representation, the match rules need to account for the full matrix of field formats.

Common cross-system formatting differences:

| System | Typical formatting variance | |---|---| | CRM | Full name in structured fields | | Identity provider | Normalized email, phone often absent | | Storefront | Guest checkout may use email only | | Loyalty platform | Loyalty ID often used as primary key, not email |

When these systems feed into the MDM with mismatched field formats, single-system match rules produce cascading false merges. This is where the Integration Foundation Sprint helps — the diagnostic maps every source system's field output against the match rule logic and identifies which handoffs are producing the mismatches.

If you have not already reviewed your address propagation across your CRM and storefront, that is a useful parallel diagnostic. See Customer Identity and MDM Operations Field Guide: Diagnosing and Fixing Customer Addresses Validated at Checkout But Not Propagated Back to the CRM for how field formats diverge across systems.

Step 5: Rule Out Duplicate Data Entry

Check whether the same customer created two accounts intentionally before concluding this is a system error.

Common scenarios:

• A customer uses a personal email for one account and a business email for another
• A B2B buyer creates separate accounts for multiple locations or subsidiaries
• A customer registers through your loyalty platform separately from your storefront checkout flow

If both records represent the same real person, the merge may be technically correct — the system did what it was configured to do, even if the outcome is operationally unwanted.

This changes the fix. Instead of a system configuration change, you need a customer communication and account consolidation workflow: contact the customer to confirm which profile they want active, then merge or suppress the secondary record through a governed process.

If you are seeing suppression list fragmentation across platforms — where a customer unsubscribes in one system but not another — that is a related symptom of the same underlying data fragmentation. See Customer Email Preferences Not Syncing Across Systems for that pattern.

Step 6: Document Everything Before Touching Anything

Before any unmerge or manual correction, capture:

• Full screenshot of both profile states (all visible fields)
• The merge audit log entry showing timestamp and match key
• The match rule configuration as it currently stands (threshold value and field requirements)

This documentation matters because undoing a merge can trigger downstream data conflicts. If orders, loyalty points, support tickets, or marketing communications are already attached to the merged record, an unmerge without documentation can leave you unable to reconstruct what happened — and unable to prove the fix worked.

Operator note: Without the audit log, an unmerge may be logged by the system as a new merge event, overwriting the original trigger record. Screenshots and log capture take five minutes. Reconstruction from backup exports takes much longer.

What to Bring to the Escalation

A clean handoff to IT or a vendor support ticket should include these six data points:

1. The two original profile IDs
2. The merge timestamp from the audit log
3. The match key that triggered the merge (email, phone, name, or composite)
4. The current confidence threshold value
5. The source systems involved for each profile
6. A ruling on whether duplicate intentional entry has been ruled out

With those six points, the fix is fast: either the threshold gets raised, the match logic gets a secondary field confirmation, or a cross-system rule variant gets built. Without them, the first hour of every escalation is spent gathering the evidence you should have brought.

If the cross-system dimension is confirmed — the same customer ID fragments arriving from your CRM, identity provider, storefront, or loyalty platform with different field formatting — that is a structural issue the Integration Foundation Sprint is built to address in the first two weeks.

When This Points to a Bigger Integration Problem

If this merge error has occurred more than once in recent weeks, the match rule configuration is not the whole story. Repeated false merges across the same source systems signal that the MDM integration layer needs a proper diagnostic.

Match rules are sometimes written to handle an original system pair — CRM plus MDM — and the loyalty platform or storefront gets added without updating the cross-system field mappings. The rules work fine within the original pair but produce cascading false merges every time a new system starts writing into the MDM.

That is the diagnostic the Integration Foundation Sprint is designed to deliver — a structured audit of every system handoff, every match rule, and every threshold configuration across your full customer identity stack.

If you are seeing this pattern, it is worth a conversation before the next incident closes your support queue.

Frequently Asked Questions

Can I just unmerge the profiles right now?

You can, but do not do it before capturing the audit log and screenshots first. Unmerging without documentation makes the root cause harder to find if the error recurs.

What if the threshold is already at 90%?

A high threshold does not rule out false merges if the match rule is single-field. A single-field match at 90% confidence can still collapse two different people who share an email domain. Look for whether the rule requires a secondary field confirmation.

How do I stop this from happening again?

The fix is in the match rule design — either raise the threshold, add a secondary field requirement, or introduce a manual review step for cross-system merges. The right configuration depends on which systems are sending data into the MDM and how consistent those field formats are.

This checklist is part of the TkTurners Omnichannel Systems content series. For the full field guide on customer identity and MDM operations, explore the series in the blog archive.