Warning: since August, I have observed on multiple Marketo instances that ALL score fields have stopped to sync from SFDC to Marketo. In the past, we could not change the value of the custom score fields in SFDC (in fact we could, but the changes were automatically overridden by Marketo), but now, the lead score field seems to behave also that way.
This is quite painful for every one who used to have an SFDC workflow computing the sum behavior + demographic and inserting this in the lead score field.
See also Weird bug with "Score" field type?
Per a discussion with Mike Reynolds here: https://nation.marketo.com/message/108801#comment-108801, it seems that the "lead score" field value should not be changed in SFDC. And that the idea of a Salesforce workflow updating the lead score field is unsupported in the first place. Here is Mike's statement:
I've double checked with other Support Engineers, including Tier 2 and our SFDC Subject Matter Experts. I also tested it in my own Stage account, and if it is in fact a score field synced directly to Marketo, then a change from the SFDC side will be overwritten by the value from the Marketo side. If you're seeing different behavior, then something is broken and you should open up a case with Support to have it checked out.
Yet, Lead score does not appear on the list if the systems fields in the doc: Understanding System Managed Fields - Marketo Docs - Product Docs . More broadly, I have not been able to find in the doc a statement about the lead score field, or any other score fields BTW, being a one-way sync'ed field.
For those of you who have a Salesforce workflow that computes the sum of behavior + demographic and store the result to the lead score, send it back to Marketo and trigger lead management actions this may not work any longer, meaning the flow of MQL's has stopped.
Can you pls check and let us know?
If this is the case, then you may want to consider the following workaround:
In SFDC : create a new "formula" field, called "Total score" (you do not need a workflow here) in leads and contacts with the following formula:
blankvalue( Behavioral_Score__c,0) + blankvalue( Demo_Firmo_Score__c,0)
Then in Marketo, create a smart campaign that copies the value of this field to the lead score field with a change data value as this:
You may want to even replace lead score with "total score" in your lead management campaigns.
For the largest companies, another solution would be to ask Marketo Professional Services to run the total in Marketo using the munctions technology.
Solved! Go to Solution.
Hi Grégoire Michel
Here’s the information I got from our engineering team.
The ability to have SFDC score changes update values back inside of Marketo was a bug and that bug got fixed when a patch rolled out to correct something else related to the changes to the Marketo Salesforce sync.
Here's what was going on:
All score fields, even custom ones, are set by design to be “Marketo-win” fields so the values on the Marketo side will always push back up to SFDC and overwrite the value on that side. That’s the expected behavior, but there was a way that behavior could be accidentally overridden. That ability to override expected behavior is the bug that was fixed.
Here’s how it worked.
There are two settings at play, the “Marketo always-win” setting and the SFDC Read-Only setting on the field itself. Score fields are set to Marketo always-win by default. If you set the field as Read-only from the SFDC side, it’s supposed to block updates from Marketo coming up to SFDC, essentially in effect creating an SFDC always-win situation. This conflict is what the bug took advantage of to force the score change from SFDC down to Marketo, despite the expected behavior. The other piece to the puzzle is that it only happens when the two field settings are set in that way to create that conflict, which is why some people experience it and others didn’t, (like we found out here and here).
What's been done:
The bug got fixed, so custom score fields will always win on the Marketo side. However, that doesn’t have to stay that way.
Changes you can make to the behavior:
If you’d like to change that setting, we can enable it to allow score changes from SFDC to come down to Marketo by putting in a service request with Engineering to switch off the Marketo always-win setting. That will make it a true bi-directional sync where changes on either side will be allowed to sync over to the other side and stick so they aren’t overwritten.
Disclaimers about changing the behavior:
What to do next:
Test this behavior out before submitting the case to Support to have it changed. Engineering has released patches to correct the behavior and you should re-test your fields to be 100% sure of what they are doing currently as of today before submitting a case asking for that behavior to be changed.
If there are any other questions at all, you can post them here, but you can also Contact Marketo Support to get answers specific to your particular use case.
This is a strangely difficult one to answer. I'm checking with our Product team directly on this one. I'll let you know when we have a conclusive answer.
Still looking into this one. I'd wait to implement a permanent solution just for a little bit until we can get a conclusive answer back on expected behavior.
I got this, but this is quite urgent though, as it has a business impact (lead with improper score that are not assigned to sales qualification).
Is this not part of this change that is taking place INFO
Based on their timeline some instances should have started in August (Accounts starting with a #).
This is also what I suggested in another thread. Mike will know and let us know, I suppose.
That's the tricky part. We had two different versions of expected behavior. Then due to an issue found during initial deployment of this configuration change, a patch went out to fix the Lead Score relationship with SFDC, and it seems like that then affected the behavior of all other custom score fields, not just the standard Marketo Lead Score. Now we're back to sorting out with Engineering and Product teams what the official expected behavior is, but we've got some urgency to it as you're seeing here.
And add to it that the "official" behavior is not in the doc... Meaning that people have made their own interpretation of the actual past behavior, which removal is causing the issue.