Sign Up ›

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Derek VansantDerek Vansant 

Cannot figure out how to stop transfer notifications

This question involves APEX triggers and APIs so I'm hoping someone can help. I've been SFDC admin and developer for over a decade but this one has me stumped.

My reps are getting flooded by SFDC generated contact transfer notifications and I have no idea how to stop them. Here' the order of events:
1) lead imported to Marketo
2) lead syncs with SFDC
3) SFDC Assignment rules applied (FYI, no email templates are used in this step)
4) Lead auto convereted by trigger and attched to Account
5) New Contact owner changed to match Account owner by trigger

There are no workflow or notification settings that I can see that would create a transfer notification...and here's the really wierd part. If I do all of the above steps, except start it by manually creating a lead in the SFDC UI, then no notification is sent. This only happens when the lead is injected from Marketo. That said, I am 100% sure the notification is sent from SFDC because I checked the email headers. So I think the answer must have something to do with some sort of API / trigger combination. Below is a copy of one of the transfer notifications.

All ideas for making this stop are welcome. Thank you very much.

-Derek

Subject: Contact transferred to you.
Body: Contact [NAME] has been assigned to you. Please click on the link below to view the record.
 
Chandra Sekhar CH N VChandra Sekhar CH N V
Hi Derek,

2 things which I want to highlight - 

1)Are there any triggers active on Contact object?

2) while transferring the contact record, is the user selecting 'Send notification email' checkbox ?User-added image
Derek VansantDerek Vansant
Thank you very much for the reply. Everything is automated, so there are no issues with users checking boxes, etc. in the UI.

There are 2 triggers involved. A trigger on the lead fires upon lead creation that does a lookup comparing the email domain of the lead to account websites. If a match is found, the trigger converts the lead and attaches the contact to the matching account. Then, a trigger on the contact changes owner of the new contact to make sure it matches the owner of the existing account. I suspect this is where the issue is occurring. How do I prevent Apex owner changes from firing alerts. Contact trigger code is below: 
trigger ContactOwnerEqualsAccount on Contact (after insert, after update) {

public list<Contact> ContactsToUpdate = new List<Contact>();

for(integer j=0; j < trigger.new.size();j++){
if(
(
trigger.isupdate &&
trigger.new[j].Account_Owner_ID__c != NULL && 
trigger.new[j].Account_Owner_ID__c != trigger.new[j].OwnerID &&
trigger.new[j].OwnerID == trigger.Old[j].OwnerID
) ||

(
trigger.isinsert &&
trigger.new[j].Account_Owner_ID__c != NULL && 
trigger.new[j].Account_Owner_ID__c != trigger.new[j].OwnerID 
)
)
{
ID owner = trigger.new[j].Account_Owner_ID__c;
ContactsToUpdate.add(new contact(ID = trigger.new[j].id, OwnerID = owner));
}else{}}

if(ContactsToUpdate.size()>0){update ContactsToUpdate;}else {}

}

 
Derek VansantDerek Vansant
Any thoughts? I'm still stuck on this issue.
Gordon EngelGordon Engel
It may be a bug.  Can you simplify the reproducer by taking Marketo out of the equation?  Optimally would like to see just steps 4 and 5 to reproduce.  If you can do that, can you file a Case with Salesforce Support?  (If you can't, then I will ask a subject matter expert to verify your repro.)
Hayk HovhannisyanHayk Hovhannisyan
Hi Derek, Gordon, we are experiencing a similar issue. In our case, it is the Form Assembly Connector and the SFDC trigger are interfering.  
FA connector has the "Send User Emails" checked off so that users can receive case assignment notification emails. 
Upon form submission we create/update contacts, before creating the related case, and that fires the trigger that updates contact ownership based on submitted country/state values. As a result users are receiving multiple "transfer notification" emails (there are a few cycles of evaluations).
 
I did not see similar problems reported previously, so that may indeed be a bug?
 
Derek VansantDerek Vansant
I have been swamped with other priorities and employed a workaround by importing directly into SFDC with the correct owner name, bypassing all the triggers. Thanks everyone for your comments.
Ryan Bobadilla 10Ryan Bobadilla 10

Just bringing this back to light.

I too have had the same issue and after changing the "DML" so many "DML" times and scratching my head, I finally stumbled across this:

"The database.DMLOptions object supports assignment rules for cases and leads, but NOT for accounts or territory management."

So, considering Contact management has to do with Accounts, I'm assuming this falls under the "NOT for accounts" option.  Please, please, anyone know what to add in APEX to stop Contact Transfer notifications from firing off when you have this type of automation!??!! 
Tiffany DeYoungTiffany DeYoung
And another year later, we'll try this yet again. We're facing the same problem with the FormAssembly connector and a trigger that transfers contact ownership. Contact transfer notifications are being sent, but only when a contact is created through FormAssembly. 

Does anyone have a solution to stop these emails from firing?
Adam JassAdam Jass
Not a developer, but experiencing this same issue, in Non Profit. Form Assembly creates a Contact, Household Account is created by NPSP. A Process Builder fires to immediately change the Account Owner to a certain person. When we introduce a delay in the Record Update, like an hour, there are no email notifications sent. If we set it to Immediate Update Records, it sends multiple email notifications from SF about the Account Transfer, on behalf of the integration user that created the Contact/Account. 

Still looking for what to do... anybody solve this 3 years later?? :)
Adam JassAdam Jass
Well after a little digging, I think this solves the situation for me, anyway:

In Form Assembly, under Connectors > Salesforce > Configure, you can scroll to the bottom and you will see a checkbox for "trigger user emails". Their help documentation says this controls whether FA will tell SF to send various emails to internal users based on a number of potential criteria, including "resetting a password, creating a new user, adding comments to a case, or creating or modifying a task." 

I tested the Account Ownership transfer emails that get sent to me because of registrations via Form Assembly. They came when that checkbox was checked, and stopped when it was unchecked. Notification emails about the form being filled in were unaffected. 

Our form and use-case is simple enough that I'm not concerned about other potential impacts of disabling that setting (but I'm keeping my eye on it). But I'm leaving this info here because the solution to this problem seems to be a case of Salesforce and a third-party integration not talking clearly to each other.
Gordon EngelGordon Engel
Internally, Salesforce has it's own trigger for ownership change. I'm guessing that if you create a process that triggers immediately on update, you are incidentally triggering the internal Salesforce notification redundantly.  By turning off that checkbox, you disabled the internal Salesforce trigger. If that solves your problem, then that's good.

This sounds like the Salesforce internal trigger needs to be able to detect that it has already fired once and not send duplicate emails. This isn't my area of expertise, but if you need this fixed you should open a Case with Salesforce.
 
Gordon EngelGordon Engel
After some more digging I found this known issue (https://success.salesforce.com/issues_view?id=a1p3A0000018As9QAE).  Is it related?

Reference: W-4287656
 
Adam JassAdam Jass
Maybe, I'm not learned enough to say for sure. Seems like that is related to Opportunities, and mine only affects Accounts. My situation is fine with my workaround, maybe others will have more of an issue. Thanks Gordon!
Chris LanceChris Lance
My use case is exactly the same as Derek's....
  1. Marketo loads in a lead
  2. Lead is auto-converted into a Contact with an APEX trigger
  3. Flow is triggered to manage record owner
  4. Salesforce's notification alert is sent to the new record owner
OR
  1. Marketo updates an existing Contact
  2. Flow is triggered to manage record owner
  3. Salesforce's notificatoin alert is sent to the new record owner

What I don't get is why does Marketo setting off Salesforce process to change record owner generate this alert while I can use a other products (DBAmp) to mass update records, essentially through the same Salesforce API, and not set off these notifications?  Maybe Marketo's native sync with Salesforce is passing a parameter through the API that is causing the record transfer alerts (or DBAmp is passing a parameter to suppress them)?
Chris LanceChris Lance
What's funny is how this article talks about how the data loader will not mass send these transfer alert emails and mentions how it's not advisable or managable to spam users with these emails... lol  - https://help.salesforce.com/articleView?id=000312786&type=1&mode=1
Gordon EngelGordon Engel
The Known Issue I linked in my previous post applies to both Opportunities and Leads.  The issue only occurs when there is a Workflow on the object, so the Marketo package probably has a Workflow running in your org. I could check if you tell me the Id or Name/Version of the Marketo package.

The workaround listed says to "Use a Before Insert trigger" in the flow: see this document (https://help.salesforce.com/articleView?id=flow_concepts_trigger_record.htm&type=5).
Gordon EngelGordon Engel
I read through more notes on this and it turns out there are multiple paths that can lead to the email notification trigger, not just from the Worflow object. That's partly why it is so difficult to fix this - different teams need to share whether an email was sent or not, and the Triggers aren't architected to expose that type of information. Even so, the "Before Insert trigger" workaround should work for both the Apex trigger use case and the Workflow use case.