Summer14: The Email Flow Element

The Summer’14 release had many nifty items that became available. This includes the new “Fast” create, update, lookup, and delete. It also includes the popular loop. You can read about some of these in my previous post Letter to the Developer: The “Date Loop” to Create Records with Flow

In addition to these fabulous new elements we also got two “Static Action” elements: Submit for Approval and Send Email. Being able to submit for approval via flow is amazing. I have a number of ideas how to abuse this, but that’s another post.

Let’s take a look at how we can use the Send Email element in Flow and how it is different than an Email Alert with Workflow rules.

Workflow Rule Email Alert Vs Flow

Email Alerts have been around for a long, long time and are a cherished and, in my opinion, overused feature of Salesforce. The email alert is tied to a workflow rule can be sent either immediate upon the workflow triggering or as an timed action.

The Send Email element can send an email anytime the element is “activated” by a flow.

There are three big differences for me. First, an email alert can be sent on a time basis. This cannot be done with a flow right now.

Second, email alerts have static “decision” of when it should be sent. It is entirely based on the criteria of the workflow rule. With Flow, we can have multiple decision elements that will decide when to send an email and which email to send.

Finally, third, an email alert uses an email template. The send email element in flow currently doesn’t support email templates. With these three differences in mind, let’s take a look at some use cases for the send email element.

The debug

A classic method of debugging flow is to create a new record that stores your variable and fault messages. This worked fairly well before you could call flow via Apex and Workflow Rule (Headless flows still in pilot). When you have a fast create or update and an error occurs any record creation is “rolled back.” This means were stuck with some debug logs and those often do not give you enough information.

Enter, the send email element! We can now send an email as our fault action. Now we can send us an email that contains the fault message and any other piece of information we want. I like to have 1 send email element as my fault. I use a text template as the body of the email and include a variable for the “culprit.” With every fault I got through an assignment element to set the value of my culprit variable. This way I can have 1 send email that sends me all the information and I know which element caused the fault.

Who gets what When

Email alerts are useful. Need a closed won notification? Easy! Need a close won notification for Product A that goes to Managers X, Y, and Z but only when the close date is in the first quarter? No problem. Need a close won notification that goes to different people for each product with other special criteria? Also no problem, but have fun creating those workflow rules.

When you have multiple email alerts that you want to send that each have their own criteria when to be sent. You would need to have a workflow rule for each and every email alert. Yuck!

With flow we could create one flow and use decision elements to decide which email(s) should be sent. Personally, I dislike having to manage many workflow rules when they are really doing a similar category of actions. With the example above if we had many 10 products we might have 10 different workflow rules – or more depending on the other special criteria. Instead, I could have 1 flow. I’ll take the flow.

What Send Email looks like

Send Email Element

The send email element is fairly simple. We have to name our particular element. We can also specify the normal fields of an email, recipient, body, and subject. Note there’s no location to use an email template. What can do is use the text template feature of Flow. You may recall the text template feature from my post Let the Salesforce Requests Flow We can use rich text with the text template and pull in other flow variables and information. Our text template therefore becomes our version of an email template. The text template is how I pass over the fault message and any other variable I want.
Text template fault message

That’s all you need to have set. You can use a variable that holds the email address or you can simply type your email address directly. The send email element is a simple way to add a layer of functionality to your flows. I’m planning on going back to my Salesforce Request flow and add a “confirmation” email.

How will you use the email element? Let me know in the comments!

Showing 8 comments
  • Kira
    Reply

    I really LOVED this post! Thanks Brian, very helpful and such a relief this gives admins going forward!

  • Pat Vachon
    Reply

    Send Email is so close to perfectly executed. Sucks that an email template can’t be dynamically chosen for it’s subject and body. Hopefully Lightning Process Builder closes this gap.

    • Salesforce Wizard
      Reply

      I agree, it would be great to be able to use email templates in the send email action. I posted an idea for that here: https://success.salesforce.com/ideaView?id=08730000000Dfk0AAC

      One thing you can do is to create an Email Alert and use the email alert instead of the send email action. That will let you use an email template but you would have to specify the recipients in the email alert and not the flow.

  • Brian
    Reply

    Are you actually receiving formatted Rich Text when you get these emails?

    I only get a plain text message with lots of markup exposed.

  • www.flvs.net
    Reply

    Brian thank you for posting this. I just got the email with the HTML markups and was wondering if I did something wrong.

    • Brian
      Reply

      I’m a total Newb here, but can I suggest… Don’t forget to hit the button that says “This Issue Affects me.”

      I’m assuming that the more people hit that, the more likely that Salesforce will do something about it.

Leave a Reply