We are recently seeing records getting a "Failed to acquire lock on SFDC Campaign" during their "Add to SFDC Campaign" flow step.
Hi Rachel,
When Salesforce goes to update a record, it first "locks" that record (row in the database) to prevent other processes from modifying it before it's finished writing the update. You're getting this error when you attempt to update a record that Salesforce has already locked for another update.
Based on the scenario you laid out, it seems very likely that your org has automation (declarative or programmatic) that updates the Salesforce campaign record when child campaign member records are added to it. Something along the lines of this:
Possible solutions:
This is a best guess and we'd need some more information to figure out exactly what's happening.
Hope that helps!
Dan
Is there any way to trigger a notification in Marketo when this happens? Or perhaps a report that could catch this?
I agree that creating a more synchronous system is the way to go, but in the meantime I want to make sure I have visibility into records.
This is an issue that we are having as well. We have not found a way to trigger an alert in Marketo, and we have not been able to see an error logged on the SFDC side. We can only see if a campaign member record fails if we compare a controlled list of batch campaign members. If it happens more organically through lead scoring or contact forms, the only way we can see the fail is if we spot check the person's activity logs in Marketo.
We have been trying to troubleshoot this issue for several months now. We are testing in our sandbox/dev SFDC environment and have deactivated custom SFDC scripts that were running to eliminate variables. We are still see this error.
Has anybody been able to solve this issue with SFDC or have any add'l "clues"?
Thanks!
We did more testing with this and we found that if you are calling the "add to SFDC Campaign" as a trigger from Marketo.. there is a possibility of a timing issue with SFDC. Marketo will treat each person that qualifies for the flow steps individually. The SFDC campaign will "lock", the member will be added, and then the campaign will be "unlocked". If a lot of people are going through the trigger campaign at the same time, there will be some records that will have timing issues with the campaign unlocking from the previous records.
Vs, if you use a batch/predefined list.. Marketo will "tell" SFDC how long to "lock" the campaign for.. it will add all of the records, and then unlock the campaign. No errors because the campaign is locked until all records that qualified for the batch are added.
I may not have that 100% technically right.. but it made sense after we did a lot of testing and understood more how the trigger campaigns, vs. batch campaigns worked between Mkto and SFDC.
In our case, we had to re-write our triggers to be batch when we were doing a larger list of people at one time.
Hope that helps! That was a hard mystery to solve on our side!
Thanks for looking into it - I'm glad you were able to find some sort of solution, even though it may not be ideal.
We ended up going back to direct MKTO program to SFDC campaign syncs. It seems to have basically eliminated the issue for us, but I understand other organizations may need to use the "add to SFDC campaign" flow step instead.
Solution: Add a 1minute wait step in the Marketo flow before Adding to SFDC campaign, so that the record updates gets completed on SFDC side.
For our case, LeanData (routing tool) was locking some records for updates.
You shouldn’t attempt to use arbitrary Wait steps when you know you have a race condition (just as you would not sleep for an arbitrary period of time in actual code). Not what the Wait feature is for... and not a recommended solution.
There’s always a better way to properly + predictably sequence events by working with your SFDC team.
I agree to this so much! @Zainulislam, there's no guarantee that holding back one of the process in race condition by 1 minute will be enough for the another process to complete. While this may seem to work fine at first (at least while testing) but you'll still see this error occurring for when the 1 minute did not happen to be enough.