Hello everyone. I've been working through a complex CRM data migration for a client this week, and a critical data quality issue has surfaced that I think is a perfect case study for this forum. The core problem is one of **source system truth**, and it's causing real friction between their sales and marketing departments.
The situation: After migrating lead data from their old marketing automation platform (Marketo) into Salesforce, we discovered that the lead scores visible to the marketing team in their new tool (HubSpot) do not match the lead scores visible to the sales team in Salesforce for the same records. Both teams are now pointing fingers, each claiming their system holds the "correct" score to prioritize outreach.
**My investigation so far has pinpointed a few likely culprits:**
* **Asynchronous Scoring Updates:** The marketing platform likely updates scores on its own schedule (e.g., nightly batch), while Salesforce might be receiving real-time or differently timed updates via an integration. A lead viewed at 2 PM might show different values in each system.
* **Field Mapping & Transformation Errors:** During the ETL process, the numerical score field might have been mapped correctly, but the logic behind it could have diverged. For example, was the score rounded, truncated, or did a formula field in Salesforce get applied post-migration that alters the raw value?
* **Differing Source of Truth:** This is the most insidious possibility. Perhaps the "score" in the old system was actually a composite of two fields (e.g., `engagement_score` + `profile_score`), and only one was migrated, while the new marketing tool calculates its own score using different behavioral events.
To diagnose this, I walked the team through a validation query on a sample of mismatched Lead IDs. Here's a simplified version of the SOQL we ran to compare values and timestamps:
```sql
SELECT
Id,
Email,
Lead_Score__c, // Salesforce field
Last_Score_Update__c, // When Salesforce says it was updated
Marketing_Score_Snapshot__c // A field we populated during migration
FROM Lead
WHERE Email IN ('lead1@company.com', 'lead2@company.com')
ORDER BY Last_Score_Update__c DESC
```
**The immediate next steps I've recommended are:**
1. **Establish a Point-in-Time Audit:** For 5-10 specific leads, capture a screenshot of the score in both systems *at the exact same moment*. Note the system time.
2. **Trace the Data Flow:** Check the integration middleware (like Mulesoft, Celigo, or a custom script) for any transformation logic applied to the score field in transit.
3. **Review the Migration Mapping Document:** Verify the source field for `Lead_Score__c` was indeed the single, correct field from the legacy system's API.
Has anyone else encountered a similar "which score is right?" scenario post-migration or during ongoing sync? I'm particularly interested in how you established the definitive source of truth and communicated that to stakeholders. Did you lock down one system as the master and have the other consume it as read-only?
The resolution here will be less about the technical fix and more about process: aligning teams on a single metric and potentially rebuilding the scoring logic in one place. Let's share some war stories.
-- Mike
test the migration before you migrate
Yep, the async scoring update is a classic silent killer. We got burned by that with a Pipedrive-HubSpot sync. Marketing's scoring model ran at 3 AM, but sales checked fresh leads at 9 AM before the sync job pushed the updated scores over. They were working with data that was 6 hours stale.
Your second point on field mapping is spot on. Did you check if one system is using an integer field and the other a decimal? We once had a score of "85.5" get truncated to "85" during a migration because someone mapped to the wrong field type. The discrepancy seemed random unless you looked for the half points.
Might be worth asking if they're even using the *same* scoring model now. Sometimes marketing tweaks their formula in the new platform and forgets to tell sales, so you're not just comparing data, but two different logics.
Build with what you have
Great point about checking the field types. The integer/decimal mismatch can create such subtle chaos, especially if the rounding logic differs between systems.
And your note about different scoring models is crucial. Even if the data syncs perfectly, you could be comparing apples to oranges if one team is using "engagement score" and the other is using "propensity to buy." I'd start by getting both teams in a room to walk through the exact attributes and weights in each platform. That conversation alone often reveals the root cause.
Async updates are the worst for building dashboards too. Had to set up a Prometheus gauge just to track the sync lag time between systems once.
Getting both teams in the same room sounds like the fastest fix. When I started, I saw a similar fight over "qualified leads." Turns out sales defined it by budget, marketing by whitepaper downloads. They were arguing over two different numbers.
So is the Prometheus gauge a common fix? We're looking at sync tools and I've never heard of using it for that.
Ah, the timeless ritual of migrating data only to create two competing versions of the truth. I've seen this movie before, and the ending is always the same: a dozen meetings and a new sync tool subscription.
Your initial culprits are the usual suspects, but let's not overlook the more cynical, human element. In my experience, a "field mapping error" is rarely just a technical glitch. It's often a political compromise dressed up as one. Did someone decide to map the *raw* Marketo score to Salesforce, while marketing is now looking at a *recalculated* HubSpot score that uses slightly different demographic weightings? I've watched teams agree on a mapping spec to keep the project moving, fully aware they'd be revisiting it as a "data quality issue" later.
And on asynchronous updates, you're right, but the real problem isn't the lag - it's that each team's process has now adapted to their local, stale reality. Sales has started ignoring scores below their version's threshold, while marketing is proudly handing over "hot" leads based on theirs. The data mismatch is just proof of a workflow divorce that already happened.
You're absolutely right about the workflow divorce. That's the permanent damage, not the data lag itself. I once consulted for a company where sales created a hidden "confidence score" in a custom Salesforce field because they'd lost faith in the synced marketing score. By the time we were called in, they had two completely independent lead ranking systems running in parallel, and the debate over which score was "right" was just a proxy war for who owned the process.
The political compromise angle is painfully accurate too. It often manifests as mapping the last *known* value during migration instead of the *calculated* value, because the calculation engine wasn't ready yet. Everyone nods, says they'll fix it post-launch, and then it becomes "legacy data logic" that nobody wants to touch.
Your point raises the real question: is the goal to make the numbers match, or to realign the teams on a single definition of a qualified lead? The former is a technical sync fix. The latter requires dismantling those adapted workflows, which is much harder.