Mark Bounced Records as Bad Addresses

The VerticalResponse integration with Salesforce is capable of pushing a lot of great statistics back to your lead and contact records.  Opens, clickthroughs, which links were clicked, bounces and unsubscribes can all be seen within the custom Email History Objects that are installed as part of our software package, plus we mark the Opt-Out box within each record should a recipient choose to unsubscribe.  This is in addition to the custom reports and dashboards we provide.

 But one thing we don’t do (mostly because salesforce does not provide a standard field for this purpose) is mark bounced records as having a bad address.  Though you can see this information within the history object and custom reports (as I noted above), the bounce data is not provided in a way that allows you to easily filter out bounced addresses automatically from Salesforce campaigns and emails that are sent outside of the VerticalResponse system.

This is an issue that VerticalResponse user Dave Manelski of www.onenw.org tackled head-on, creating a work-around that uses our provided statistics to flag bounced contact records as having a Bad Email Address (which is a custom contact field that he created).  Our Product Managers have tested his work-around and it works great, so I wanted to pass this information on to all of you.  Note that you’ll need to be a Salesforce expert (or have access to an expert administrator) to set this up. 

I’ll let Dave introduce his work:

One of my colleagues on the development team has been using Vertical 
Response to send invitations to an upcoming workshop that we're 
hosting on email and actions alerts best practices.  She was 
disappointed that bounced emails in Vertical Response weren't 
reflected on the contact records in our database. Therefore, contacts 
with outdated email addresses were still being added to campaigns, 
giving a false picture of our actual engagement with some 
constituents.  Rather than deal with these records by hand, we crafted 
a trigger to handle bounces.  Here's what it does:

When you Update Statistics in Vertical Response's App Exchange tab, 
Vertical response sends over a bunch of child records (to Contact) 
called VR Email History Contact for each contact you've emailed 
through Vertical Response.  When one of these VR Email History Contact
records is marked as having been Bounced, the contact record is updated
and flagged as having a Bad Email Address (a custom boolean field on Contact).

It's a quick and dirty work-around until Vertical Response comes up 
with a different solution.  I've posted the code and test below.

trigger ONEN_Contact_MarkBadEmail on vr__VR_Email_History_Contact__c 
(after insert, after update) {

        // every time we a VR Email History is added to the contact record, 
or updated from Vertical Reponse
        // and the VR Email History Contact has a bounced checkbox marked as 
true, update the contact field
        // Bad Email Addresss to True.

        // declare an array of Contact Id's that will come from the list of 
VR Email History records that
        // have the Bounced checkbox checked (true)
        list<Id> ContactIdsToUpdate = new list<Id>();

        // declare a new variable to hold VR Email History records with 
bounced emails
        vr__VR_Email_History_Contact__c BouncedEmail = new 
vr__VR_Email_History_Contact__c();

        // declare an array of contact records to update that will be 
associated with our list of
        // Contact Id's
        list<Contact> ContactsToUpdate = new list<Contact>();

        // loop through a batch of VR Email History records, for those 
records that have Bounced checked,
        // pull the contact Id's and throw them into a list
        for (vr__VR_Email_History_Contact__c thisEmailRecord : trigger.new) {

                if ( thisEmailRecord.vr__Bounced__c) {
                        ContactIdsToUpdate.add (thisEmailRecord.vr__Contact__c);
                }
        }

        // With our list of contact Id's, pull those contact records, set the 
Bad Email Address field to true,
        // and throw those contacts to update into a list
        if ( ContactIdsToUpdate.size() > 0 ) {
                for (Id BouncedContacts : ContactIdsToUpdate) {
                        Contact thisContact = new Contact (
                        Id = BouncedContacts,
                        Bad_Email_Address__c = true
                        );
                        ContactsToUpdate.add (thisContact);

                }

                update ContactsToUpdate;
        }

}

public class ONEN_Test_Contact_MarkBadEmail {

        static testMethod void Contact_MarkedAsBadEmail () {

                //Create a new contact record with Bad Email Address (custom boolean 
field on Contact) unchecked
                Contact testContact = new Contact (
                        LastName = 'Schmoe',
                        Bad_Email_Address__c = false
                );
                insert testContact;

                // Assert that Bad Email Address is indeed false on our newly create 
contact record
                Contact testContact1 = [select id, Bad_Email_Address__c from Contact 
where id=:testContact.Id];
                system.assertEquals(false,testContact1.Bad_Email_Address__c);

                // Create a new Vertical Response email history record with the 
contact Id of the contact record created above
                // and with the Bounced checkbox unchecked (false)
                vr__VR_Email_History_Contact__c testEmailHistory = new 
vr__VR_Email_History_Contact__c (
                        Name = 'Test Campaign Email',
                        vr__Bounced__c = false,
                        vr__Contact__c = testContact.Id
                );
                insert testEmailHistory;

                Contact testContact2 = [select id, Bad_Email_Address__c from Contact 
where id=:testContact.Id];

                // this shouldn't have triggered the code, so Contact should still 
be false
                system.assertEquals(false,testContact2.Bad_Email_Address__c);

                // Create a new Vertical Response email history record with the 
contact Id of the contact record created above
                // and with the Bounced checkbox checked (true) -- this should kick 
off the trigger to update the contact record.
                vr__VR_Email_History_Contact__c testEmailHistory1 = new 
vr__VR_Email_History_Contact__c (
                        Name = 'Test Campaign Email',
                        vr__Bounced__c = true,
                        vr__Contact__c = testContact.Id
                );
                insert testEmailHistory1;

                // Assert that the Bad Email address on the contact record has been 
set to true when the
                // VR email history record is bounced
                Contact testContact3 = [select id, Bad_Email_Address__c from Contact 
where id=:testContact.Id];
                system.assertEquals(true,testContact3.Bad_Email_Address__c);
        }

Let us know if this works for you in the comments!  Dave has brought some other work-arounds to our attention and we’ll likely be highlighting them in the future.

Richard Huffaker, Community Education & Training Manager

Comments

[Paul Sommer]

Hello Dave,

Thanks for the trigger! I'm running the test from Eclipse 3.3.2 w/the latest Apex plug-in and am seeing a System.Exception. More specifically, the last line in the test cls

"system.assertEquals(true,testContact3.BadEmailAddress__c);"

is evaluating to false when it should be true. Have you seen this behavior? I copied over the trigger code verbatim, so I can't think of why it would fail. Thanks for any insight you can provide.

[Stefan]

Can anyone tell me how install this trigger in a Production environment.

I have asked Vertical Response but there response is not at all helpful.

[Richard Huffaker]

Hi Marc,

I think it would be a great idea for this to become part of the standard VR for AppEx product, and I've been discussing such a possibility with the Product Managers. But I'm not sure if this is something we'll see in the near future.

[Richard Huffaker]

Hi Lindsey,

This should work just fine even if you implement it after the email has been sent. We send the necessary data over every time you use the Update Statistics button found under the VR Email and VR Statistics tabs within your account.

[Richard Huffaker]

Hi Romina,

We do include a bounced field within our custom reports. To find this data go to the Reports section of your Salesforce account and use the Report Folders drop down menu to select VR Email History Lead or VR Email History Contact.

[Romina]

Why cant VR just create a field in thier reports that catagorizes bounced email addresses so we can easily sort through those that are bad from those that are blocked?
Is this something that we can expect to see soon?

[Alicia]

Where do you recommend the code be posted?

[Lindsey]

Great information, thank you very much!

Do you know if this works after the release has been sent or does this need to be implemented prior to sending in order to work?

[Marc Baizman]

Any chance this could become part of the standard VR for AppEx product?

I recognize that Salesforce doesn't provide a standard field for this, but it's fairly easy for SF Admins to create a custom "Bad Email Address" checkbox and put it on the page layout. What do you think?

[Stefan]

This would fill an enormous gap in the Vertical Response add-in and really should be a core part of the app.

In the meantime, would appreciate advice as to the steps I need to take to install this in our Salesforce org