I'm wrapping up a 6-week Data 360 project for a global financial data company. The goal was simple to say and hard to build: one view of each person on the Salesforce Contact page, even when that person exists as three Contacts, a Lead and a record in the master data system.
Short answer: ingest only what identity resolution needs, key identity on the MDM ID with a tightened email rule as the fallback, bring warehouse data in from Databricks, and keep reading CRM records live from Salesforce. Use the unified profile to decide who belongs together, not as the source of field values.
The Setup
- Salesforce CRM with years of duplicate Contacts, plus Leads for the same people
- Informatica MDM as the master for who a person is. Every Contact carries an MDM ID, at least in theory
- Databricks as the enterprise data warehouse, holding meeting notes and attendee data the sales team wanted on the Contact page
- Data 360, already licensed and shared with the marketing team
Lean Model vs. Comprehensive Model
The first plan ingested almost everything: opportunities, activities and the rest of the CRM objects, all mapped into the data model. It looks thorough on a diagram. In practice it means more streams to maintain, more credits every refresh, and a copy of CRM data that's always a little behind.
We pivoted to a lean model. Data 360 ingests Account, Contact, Lead and the Contact Point objects, which is what identity resolution actually needs. Opportunities, activities and other CRM records are read live from Salesforce on the page. The client confirmed the base objects as the plan of record.
The rule I'd give anyone starting out: if a record already lives in Salesforce and the page can query it, don't ingest it just to read it back.
Getting the MDM ID Into Identity Resolution
Identity resolution doesn't match on a custom field on Contact. It matches on the data model, so the MDM ID has to become a Party Identification record.
A batch data transform reads each Contact's MDM ID and writes one Party Identification row per Contact, with the identification name set to MDM_ID. It filters out three kinds of bad data before they can cause false merges:
- Blank MDM IDs
- Placeholder IDs the source system uses when it doesn't have a real one
- Any ID shared by more than 10 Contacts, which is almost always a data problem, not one person
The transform runs daily, scheduled before the identity resolution run, so new MDM IDs are picked up the next day.
Match Rules
The ruleset ended up with:
- MDM ID: exact match on Party Identification where the identification name is MDM_ID, with match on blank turned off
- Lead to Contact: keeps a converted Lead linked to its Contact
- Email: exact normalized email
Email alone is the weakest rule in most designs, and shared mailboxes are the reason. Two analysts on the same team inbox merge into one person on email alone. My recommendation is to tighten it with last name, and to keep role-based addresses like info@ and research@ out of matching entirely, using the same "shared by too many people" pattern as the MDM filter.
Accounts aren't unified. The project was about people.
The Shared Ruleset Problem
Data 360 orgs often have one identity ruleset that marketing already depends on. Changing its match rules changes their unified profiles too.
We added the MDM rule to the shared ruleset, because MDM rows only come from Contacts and can't create merges between marketing-only profiles. The plan is for marketing to sign off before the first run, with a separate ruleset on Individual as the fallback if they object. Get that conversation done before you touch a shared ruleset, not after.
Databricks as a Source
The meeting notes and attendee tables live in Databricks. We set up the Databricks connector in Data 360 with identity provider based authentication and brought in the notes extract and attendee tables, set up and tested in a UAT sandbox first.
Live Values, Not Reconciled Ones
This is the decision that kept the build small. The Contact page reads live Salesforce values. The unified profile is only used to find which Contacts and Leads belong to the same person, through the identity link records. Field values never come from the unified record.
That means no custom reconciliation rules, no fight over which source wins for phone number, and no stale data on the page. If you're tempted to build reconciliation rules, check first whether anything actually reads the reconciled values.
What I'd Tell Anyone Starting a Data 360 Project
- Start lean. Ingest what identity resolution needs and read the rest live
- Put your master ID into Party Identification with a transform, and filter bad IDs before they merge people
- Never rely on email alone. Add a name and keep shared mailboxes out
- Record a baseline before the first identity run (how many Contacts have a valid MDM ID, how many were filtered) so you can show coverage improving
- If the ruleset is shared, get sign-off before the first run
If you're scoping Data 360 and want a second opinion on how lean your model can be, book a call. More on how I run these projects on the Data Cloud consulting page.