Why Match & Merge Behaves Differently in Cloud MDM (And What Most People Miss)



This content originally appeared on DEV Community and was authored by Sujeet Patel

When I moved from traditional on-prem MDM to the cloud version of Informatica MDM on IDMC, one of the first surprises came during something I thought I already understood: match & merge logic.

I had already spent years working with match rules, comparators, survivorship, trust — so I assumed this would be a straightforward migration.

I was wrong.

What I quickly realized was that even though the concepts were the same, the way the Cloud MDM engine handles match/merge is different enough that we had to rethink a lot of things from scratch.

Here’s what I learned, and what you should be aware of if you’re making the shift.

**🧠 Rule Design Has Moved to UI, But Complexity Remains
**In on-premise projects, we often had fine-grained control using XML configs and custom user exits. With IDMC:

You design match rules directly in a no-code visual interface

You configure comparators and thresholds using dropdowns, not XML

Survivorship rules are set at the Business Entity level with weights and conditions

Sounds simple — but here’s the trap: Less code doesn’t mean less logic.

If you don’t deeply understand how fuzzy match behaves in real datasets, your merge behavior will start giving unpredictable golden records.

**⚠ The Things That Caught Us Off Guard
**In one implementation, our phone and email fields were matched too loosely. The system started merging distinct customers just because their landline numbers were similar.

That’s when we realized:

Default thresholds in cloud match rules aren’t always ideal

You must test rules on high-volume, real-world data before approving

Merge preview is your best friend — but it doesn’t always expose corner cases

**🔍 What Changed From On-Prem Logic
**Some differences that matter:

Blocking Strategy: The way IDMC clusters potential matches is different. You’ll see more groups unless your blocking fields are tight.

Merge Survivorship: You can’t override via custom code — only trust weights and rule priority matter.

Audit Logging: Merge actions are captured differently — check your job logs, not just data view.

**📘 Suggestion for Teams New to Cloud MDM
**Before you finalize any match rule in Cloud:

Run at least 2 rounds of test loads with variation data

Use synthetic data to force edge cases (e.g., 2 customers with same name, different address)

Don’t carry over your old thresholds — design from scratch

Spend extra time on merge preview before go-live

And always document your trust rules with business logic behind them — not just field weights

**🧩 My suggestion:
**If you’re new to this, try configuring a simple fuzzy match on name + email in a sandbox tenant — observe how blocking and merge behave across 100 records. You’ll catch more insights than reading 10 pages of documentation.

**🔗 Want to Learn This With Real Data?
**If you’re exploring Customer 360, match rule design, and IDMC architecture in practice — here’s a real-use case training that walks through it, start to finish:

👉 Informatica MDM Cloud SaaS Training – Customer 360 Logic Explained

Cloud makes it easier to configure — but harder to guess what’s happening underneath.
The only way to master match & merge in Cloud MDM is to test, tweak, and observe.


This content originally appeared on DEV Community and was authored by Sujeet Patel