SharePoint Workflow Emails Using HTML
- July 17th, 2013
- Posted in SharePoint
- Write comment
I've been bashing my head against the wall trying to understand why custom HTML used in a SharePoint Workflow "Send an Email" Action looked so awful when delivered. In short, there seemed to be many more carriage returns, or new lines, than there should have been. I was also having issues getting table background colors to render, and forcing externally referenced images to show.
Inserting Custom HTML into Workflow Emails
Well, the good and bad news was that the answer was right under my nose the entire time. Here's how I tracked down the last 2 issues mentioned above. To add a background color to a table, insert an image, or implement any other custom HTML, you need to insert the raw HTML into the Advanced Properties window of the Send An Email action (reference). Simply highlight the Email Action in your workflow and from the Top Ribbon select Advanced Properties > Body > and "…". From there, you can insert HTML directly into the body of your email. And it works perfectly, unless you are forgetting one simple thing.
"Optimizing" Workflow Emails
SharePoint likes to handle HTML very "differently" then most applications. That goes for all other Microsoft products frankly, and HTML in Workflow emails is no exception. The key point to remember is that Workflow Emails containing HTML are expecting everything to be in one long string (reference). No line breaks or carriage returns between any of your tags can be present. Technically, this does shave a few hundred bytes (or maybe even a KB) off the document size, and could thus be considered "optimized." However, the main issue here is that we are already jumping through so many hoops when working with the SPD String Builder (i.e. the Body editor of an email): Copy/Paste is not possible, for instance, unless all "Lookups" have been removed. By forcing HTML to be one long string we now introduce another issue where the HTML becomes nearly unreadable to human eyes should troubleshooting or future modifications be required.
Just to verify that indeed SharePoint expects HTML to be one long string, we can do the following. Create a new "Send an Email" action and include some generic text, without using html. Something like this:
If we then use the steps above to access the Advanced Properties of the Send an Email action, we will see exactly what has occurred behind the scenes:
Thus, we need to follow suit if we wish for our emails to render even remotely close to what our markup dictates. Seriously though, I assumed the DTD for SPD 2010 was HTML 4.0, but HTML 3.2??? OMG! These days, most modern Email Clients will accept at least XHTML 4.01 Transitional, and that is the markup DTD that I am now using for all my SPD 2010 Workflow emails.
Final Note on SPD 2010 "Optimization"
Back in the days of SPD 2007, it was really easy to Optimize HTML for pages that were not connected to a SharePoint site. You could just go File > New > HTML Page, paste in your HTML, and Optimize it. This really elevated SPD from being strictly a SharePoint tool to a handy Webmaster tool overall. The Optimize functionality still exists in SPD 2010 – its buried in the menu Ribbon under Spelling > Optimize HTML > Remove Whitespace > HTML all whitespace. However, by the nature of SPD 2010, this feature can only be used on a page that "lives" in a SharePoint site. So in theory you could create a document library that contains workflow HTML templates, in a human readable form, and whenever you need to Copy/Paste the HTML into a workflow, just temporarily run the Optimize HTML function against your page, Copy/Paste the "Optimized" HTML into a workflow, and close the HTML page in SPD without saving it. While this isn't a terrible idea, it does seem counter-intuitive and clunky in some ways, but maybe it's just me being difficult.
No comments yet.