How I Use Vertical Response's Email Builder to Create Formatted HTML Email Notifications for Salesforce Workflow Rules

When you've been a Salesforce Administrator for a decent length of time, you might look back on the way you implemented certain features or customized the application and be struck with this thought: "Knowing what I know now, I wish I would have done it differently."

That's the situation I found myself in as I reviewed some of our workflow rules and email notifications recently. 

Most of the email notifications were plain text and rather... blah.

So I decided to spiff them up with a little help from the html email editor that I use for creating marketing email campaigns: Vertical Response for Salesforce. 

Perks: 

• It's free to design emails with the Vertical Response WYSIWYG editor. 
• It's easy to use.
• You can paste the resulting html directly into your Salesforce email template.

Why do I use Vertical Response's editor instead of the Salesforce editor? I like to use the 'Custom (without using Letterhead)' template creation option, which means I would have to code all the html by hand. No thanks. 

Here's my process: I start off by having two tabs open. 1) 'VR Email' tab in Salesforce, 2) my new Salesforce email template, with the option of 'Custom (without using Letterhead)' chosen.

Then I proceed with the following steps:

Step 1: Design the email in the Graphical Editor.

I create a new draft email in Vertical Response. 

I like to use a centered table to make the email a bit more visually appealing.

In this example, I pasted the field names from Salesforce so that they would merge correctly.

When I'm done with my editing, I save the draft. If I need to make changes in the future, I can just come back to it in Vertical Response, make my modifications and replace the html in Salesforce with the updated version.

Note: I recommending doing all your copying and pasting text into the VR editor before you attempt to format your text. I've noticed that if I copy and paste (even if I use 'paste unformatted'), it strips the existing formatting of my entire email. Blargh. So, save yourself the frustration and get all your content in there first before you begin modifying fonts, sizes, etc.

Step 2: Preview the email.

If there are any basic formatting changes to make, it's easier to do them now than manually in html.

Step 3: Copy the code from the 'HTML Code' tab.

After selecting all the html, I copy it and switch over to Salesforce.

 Step 4: Paste the html into the 'HTML Body' area of my email in Salesforce.

Step 5: Click on the 'Preview' button and admire the result. 

Step 6: Click Save.

Now my fancified new email template is ready for circulation. It's a big improvement over the plain text version!

---

Coming Soon: In my next post, I'll show you how I used this method to redesign my 'new user welcome' emails and promote my brand within the company as a Salesforce Admin.

A Quick Fix to Prevent Getting P.O.’d - #DataQuality @Salesforce

As a Salesforce admin, I am fairly attentive to data quality.

It seems that inconsistencies and typos abound in address-related information.

So, I have a few automated tricks up my sleeve to keep our data clean.

The Problem

According to the USPS address standards, the proper abbreviation for post office box is:

PO BOX ####

Many users when entering these types of addresses, type “P.O.” This is unnecessary.

To help enforce consistent standards, I have set up a workflow rule that does the following:

• (Account: Billing Street CONTAINS P.O.,P. O.,p.o.) OR (Account: Shipping Street CONTAINS P.O.,P. O.,p.o.)

I have two field updates connected with the rule. They are:

1. SUBSTITUTE( BillingStreet , "P.O.", "PO")
2. SUBSTITUTE( ShippingStreet , "P.O.", "PO")

I have created another rule to process Contact addresses in the same way.

The nice thing about using a workflow rule with a field update is that the user doesn’t have to take any action. The data is tidied up without either of us having to lift a finger.

Yay.

Update (as of 4.29.2011)

@eliz_beth had a question about how to include if the street address has “A.P.O” in it as well. I haven’t run across this in my org, but I think the following modification would work.

Step One: Update the Workflow Rule criteria. Including “A.P.O” is a bit redundant, since it would find it using “P.O.” as well. But, I figured I would include it anyway.

Step Two: Update each of your field updates (for BillingStreet and ShippingStreet) to include the following logic.

Since the IF statement first evaluates whether the BillingStreet contains “A.P.O”, it should perform correctly by replacing “A.P.O” with “APO”. If the string does not contain “A.P.O.”, only then will it proceed to the next criteria. If it contains “P.O”, it will replace it with “PO”. This prevents it from updating “A.P.O” to “A.PO”.

I haven’t tested this, but I’m pretty sure it will work as expected. :) (famous last words)