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.
Recent Comments