Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm assigning lead ownership via apex triggers (before insert, before update) and would like to not have it send out the "Lead: [full name] has been assigned to you" email to the new owner. How do I stop those from going out?

Side note: I'm assigning via apex trigger because it's dependent on some other territory assignments that happen based on address during the before insert and before update triggers already, so I'm not interested in Lead Assignment Rules as a solution...

share|improve this question
up vote 4 down vote accepted

You want to use the DmlOptions.EmailHeader Class for this. The class has 3 properties that can send or suppress system emails. The property you are looking for is triggerUserEmail. Here is an example of how you would use it

 Database.DMLOptions options = new Database.DMLOptions();
 options.EmailHeader.triggerUserEmail = false; 

 options.EmailHeader.triggerAutoResponseEmail = false;
 options.EmailHeader.triggerOtherEmail = false;

 database.update(Record_or_List of records, options);

Here is a link to the documentation


If you are working with beforte triggers, this will not work. From the docs

it only applies to DML calls made after the DML options are applied. I.e. you would need to generate a list of objects to insert/update and set DMLOptions on them.

Here is a knowledge article that gives the workaround of using future methods to make this work

share|improve this answer
Thanks for clarifying that for me. However, any way to suppress while in a before insert or before update trigger context? Would I need to launch an @future to update these? – Nathan Williams Sep 4 '14 at 18:15
Ahhhh yes, I missed that part of your question where it stated these were before triggers. Yes, a future method is the way to go. I have updated the answer and added a knowledge article. – Chris Duncombe Sep 4 '14 at 18:19
Thank you, sir. I'll implement that shortly and let you know how it goes... – Nathan Williams Sep 4 '14 at 18:20
Oh man, I am now running into an issue where that @future is failing unit tests because i have a batch job that updates lead records (Future method cannot be called from a future or batch method). Any ideas? – Nathan Williams Sep 4 '14 at 21:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.