function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

after update trigger

Hi all,


I'm a newbie in SF development area. I have a quick question about the triggers.


I read that update() in APEX is like UPDATE in SQL, so an "after update trigger"should fire whenever there is any change to any entry in sObject. Is this right?


The reason I'm asking this is that I have written a trigger that updates a field in a case when Account's PersonBouncedEmailDate is updated. So when we get a bounce email, it will update the PersonBouncedEmailDate for the row in Account, and that should fire this trigger I wrote which will update a custom field. (You can kind of guess where my company's using this trigger).


This trigger is however isn't firing at all. It fires when I manually update one of the fields (phone for example), but it doesn't fire when we get bounced email.


Any help will be appreciated.




It sounds like you're expecting a bounced email to fire a trigger on a Person Account - is that right?


I don't believe you can have bounced emails fire features like workflow, validation rules, & trigger - it's a silent update.


You could create a daily batch process to query for PersonAccounts WHERE PersonBouncedEmail==Null AND EmailBounced=True, & batch update the date for those.


You can write a trigger for Emailmessages,that will call whenever mail comes



But bounced emails are not stored as EmailMessage objects... are they?

Automated system events (such as updating the bounced field) won't trigger Apex code. You can only rely on triggers being evaluated when a user actually causes an event to happen (i.e. data loader, web to lead, user clicks Save, etc). This is primarily to prevent infinite recursion from triggers that might otherwise occur when automated system events occur.


Edit: Obviously, incoming messages to an Email-to-Salesforce service will cause the Email handler to trigger, but bounced emails don't get stored this way-- they actually use a special return-path mechanism built into SMTP to notify the server that the email bounced, which then causes the aforementioned non-triggerable automated system event to occur.

Message Edited by sfdcfox on 11-10-2009 02:48 AM