DEV Community

Sujeet Patel
Sujeet Patel

Posted on

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

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.

Top comments (0)