What Most People Miss About Match & Merge in Cloud MDM (And Why It Behaves Differently)
Sujeet Patel
When I started working with Informatica MDM Cloud SaaS, I assumed match and merge logic would work exactly like it did in our on-prem projects. Same rules, same comparators, just a cloud UI wrapped around it.
But the deeper we got into actual IDMC implementations, the more we realized — the cloud version behaves differently.
The basics are the same. You still deal with match tokens, comparators, trust, and survivorship. But how they interact inside IDMC’s cloud-native engine is different enough to create real surprises if you're not careful.
In this post, I’ll break down what changed, what we missed, and how to avoid those mistakes.
🧩 Cloud MDM Simplifies the UI — But Not the Logic
Yes, the Cloud MDM Designer gives you a drag-and-drop interface to build match rules. No more editing XML or writing Java-based user exits.
But here’s the catch — just because it’s easier to configure doesn’t mean it’s easier to control.
We had one scenario where customers with similar phone numbers were being merged — even though their emails were different. Why? Because our fuzzy match thresholds were too loose, and we didn’t tighten the blocking logic.
That kind of mistake is hard to catch unless you're thinking beyond just UI clicks.
⚙️ What’s Actually Different in Cloud MDM Match/Merge
No coding override: You can’t inject custom logic using user exits. You rely 100% on the configuration options given.
Blocking strategy is stricter: Cloud MDM auto-generates match sets differently. Loose blocking = bigger false positives.
Survivorship is trust-first: Field-level override is now weight-based. You can’t manually force values like before.
Preview is limited: Match preview UI is useful, but it doesn't expose all edge case merges unless tested properly.
⚠️ What Most People Miss
Most beginners (even experienced on-prem users) assume:
"Same rule = same behavior" — Not true in cloud
"UI preview is enough" — You need real data testing
"If the rule runs, it's fine" — It might be silently wrong
We saw issues in production where:
Phone number match threshold merged different customers
Email case sensitivity caused false negatives
Hierarchy merge created looped parent-child records (just from logic gaps)
All of these passed the UI check — but failed on real data.
✅ My Suggestion
🧩 If you're starting fresh with Cloud MDM, here’s what I recommend:
Run match rules on both sample and edge-case records
Don’t copy thresholds from on-prem projects — design new
Document your trust strategy field by field, not just globally
Use dummy data with intentional conflicts to force behavior
And don’t assume the rule works until merge results match your intent
📘 If You Want to Go Deeper
I’ve built out a full Informatica MDM Cloud SaaS Training program where we focus on real project logic: match/merge behavior, Customer 360, survivorship configuration, and IDMC architecture — using practical examples and live use-cases.
🧠 Final Thought
Cloud MDM doesn't break the logic — it changes how it behaves.
And if you carry old habits into a new environment, you're going to see unexpected results.
Don't just rely on configuration wizards. Test deeply. Observe merge results carefully. And treat every rule as a mini design project.
Because once that data is merged incorrectly — there's no going back.
Subscribe to my newsletter
Read articles from Sujeet Patel directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by