In Automation, Blog, Flow, Releases, Tips & Tricks

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 on 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, an overused feature of Salesforce. The email alert is tied to a workflow rule can be sent either immediately upon the workflow triggering or as a 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 we’re 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 an 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 has 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!

Recommended Posts
Showing 8 comments
  • Kira

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

  • Pat Vachon

    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

      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:

      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

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

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


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

    • Brian

      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

This site uses Akismet to reduce spam. Learn how your comment data is processed.