Is this relevant for both SFDC and MSD?
Yes and no. The batch size of 10k per sync operation is the same, and the recommendations for getting around the backlog would work with MSD also, but there's a difference in the sync cycle operations because the objects in MSD are different than those in SFDC. Core concept is essentially the same, but the objects are different.
Great post here, I understand the sync objects priority, but how do field changes impact backlog? Does it matter if 10,000 records have one field update or 30 field updates? Would the backlog be the same or would more field updates cause the backlog to slow down even more?
Mike Reynolds - One of my clients was having a big problem in December of 2017 due to the sync objects priority. At that time, we were told that in the standard order of priority lead conversions were processed only after accounts were updated. The list up above in Jason's post seems to indicate the opposite.
The problem we were having a year ago - and seem to be having again now - is that there are times when Marketo sees a lead-to-contact conversion as a "New Person." Then later (sometimes over an hour later), you see a correction - Marketo executes a "Merge" on the 2 records followed by a "Convert Person" event. This causes all kinds of problems because the "New Person" event causes campaigns with "Person is Created" or Data Value changes->Previous Value is NULL" triggers to fire.
I'd like to confirm the "standard" order of priority so as to better understand what I'm seeing now. A year ago, Marketo made a change to the order of priority for us that seemed to make the problem we were seeing then better. I'm wondering if this got reversed because now we're getting double demographic scoring caused by New Person events caused by conversions.
(I have logged a support case on this. Just want to confirm how things are supposed to work).
Thanks in advance!
Hi Denise Greenberg,
Best bet would be to check with Support, and it sounds like you already have a case open. I'm not doing direct support any more, so I'm not as well versed as I was previously. But, I know our Support team will have the most current and the most accurate info. Mention this discussion thread in the case so we can get an update here if any details need to be corrected.
Thanks very much. I have just done so. In the meantime, I wonder if you remember enough to just clarify something for me. If the above is correct - which bullet point includes pulling new Contacts that were created. In my (unfortunately sketchy) notes from a year ago, what I wrote down was that Marketo was re-ordering things for us so as to pull "what Contacts had been created" after "what Leads had been converted." I'm having a bit of difficulty reconciling that terminology with the terminology above.
Denise Greenberg - we're dealing with the same issue where Marketo counts a lead to contact conversion as a new person creation. I'll raise a ticket too but would be interested to see if Marketo Support was able to help offer a solution for you. This is impacting our lead scoring program since the person's score values are essentially doubled every time this happens which is so misleading.
We've recently come across this issue on the MS Dynamics side (especially after upgrading to v9). Although, in our case, the dupes remain and require manual intervention to dedupe. But the biggest issue is the "new" record is now the active record and contains no prior activity. Is this what you're seeing on the SFDC side (if only temporarily)?:
Duplicate records created in Marketo after upgrading to Dynamics 365 Online v9
Wow that's even worse! We don't get any dupes in SFDC or Marketo after this happens.
I have seen two instances of this - where the conversion syncs over as a new (Contact) record and Marketo does not catch up later and merge it, resulting in duplicates on the Marketo side. I don't know how many other instances of this there may be lurking that I haven't caught. This is clearly another result of the same underlying problem and the Marketo Support escalation team is aware of it. I'll report back specifically on this, too.