A Salesforce Administrator’s Journey: today I learned about creating Email Alerts with Flow

Rob Clough
5 min readMay 10, 2021

Whew, this will be more than a day’s worth of TIL. This week I learned… Flow is awesome and getting better with each release but with great power comes a different way of thinking. I learnt that from Spiderman. There’s a fundamental bunch of logic stuffs that you need to get your head around before you can get the most out of Flow and it’s stuff that might be second nature to a Developer but to us Admins, maybe not so much. Admins are a multi-disciplined breed; some are more technical, some are more customer (user) focused and some are more creative. None of these traits are mutually exclusive but it’s rare you’ll find someone with all 3. And all of that is a total digression…

My aim here is to try and break down some of the different functions in relation to a Flow I made recently and from a less technical perspective; to give some tips and tricks that I’ve picked up.

Variables

I get the principle of variables but it took a few Flows for the significance of them to start sinking in. In particular I’ve been building an email notification Flow recently and I found that I needed to use variables to create ‘mail merges’. The Flow is triggered by a case priority change to serious or critical. So I added variables for all the mail merge fields I wanted to include in the alert notification i.e. Case Owner’s First Name, Case Number, Account the Case relates to etc.

Text Templates

Then you use a Text Template variable to build a Rich Text ‘Body’ for your email Action and insert your ‘mail merge’ variables using the standard format:

{!variablename}

So the Text Template variable looks something like this:

Then slots into the ‘Send Email’ action like this:

Note that variable goes into the ‘Body’ field but the actual Rich Text function is enabled by using the standard ‘TRUE’ variable as above, which seems an odd way of doing things but I’m sure the Devs had their reasons, eh.

It’s not obvious. At least, I don’t think it is, but once you get it you can start using variables for everything. An example if this is how in a previous Flow I hard coded a User’s ID into multiple steps in a Flow. Now I know that I could have set the User’s ID as a Variable and then just use the Variable and the Variable would be called, ‘User***’sID’. This makes is a lot easier to see what is happening in any given step because you don’t need to remember or check up on what the ID relates to if you’re not sure — it’s now named.

Collection Variables

One key thing to know about collection variables is that they aren’t just used in Loops. As I found out today (yes, this is the TIL) you can use collection variables in Assignments. Assignments are awesome so i’ll go on to those in a bit but you’ll see in the above Send Email action that I used a Collection variable to dynamically build the email recipients list — very cool.

Loops

Loops are pretty intimidating and I still haven’t got my head around them well enough to explain so i’ll probably leave this section as a placeholder and update it later once I’ve used them a few more times.

I would say that they are used to collect and store (cache) data from multiple records. Hence why they used in conjunction with Collection variables.

Assignments

Assignments are where you can add some nice logic and calculations and I’m sure I’ve only just scratched the surface. The example, that inspired this post, is where I used an Assignment variable to collect a range of email addresses that could be used in conjunction with the above Email Action.

The request was to set up an email alert for case’s that are changed to a priority of serious or critical. The alert would go to the owner, the owner’s manager and if it was critical, the owner’s manager’s manager. This is a bit of a pain to do via workflow but not impossible. There was one extra criteria though; the notifications shouldn’t go to any Senior Leadership Team members. Ah… There would be no way to know if the alert would get that far up the management chain and at what stage, so I somehow needed to filter out the relevant SLT users dynamically. The solution was brilliantly simple.

I used an Assignment logic node to build the ‘CaseNotificationRecipients’ collection variable based on the email addresses I extracted from a bunch of Record lookups, further back up the Flow. This has allowed me to not only build a dynamic email recipient list (of up to 5 addresses — TBC) but to actively remove certain hard coded email addresses for users that should never receive a notification. I used the ‘Remove All’ operator to ensure that those addresses could never find their way into the ‘CaseNotifcationRecipients’ collection variable. Very simple but effective nonetheless. The end result looked a bit like this:

So there we have it; some tips on Flow, a quick intro into the new Rich Text email function and a cool way to use Assignments and build dynamic email recipient lists. Value for money or what.

Before I sign off, a word of caution if you haven’t already come across this. With the latest Flow release, Salesforce have added the awesome ability to trigger Flows based on Record changes. This is the biggest step towards removing the need for Workflow and Process Builder. Except they didn’t quite make it across the line. Why? For reasons that are not immediately obvious, you can now trigger a Flow from a Record creation or update but you can’t debug the Flow. The Debug simply doesn’t work and you can’t manually enter a record ID like you could if you were triggering from elsewhere. So you have to build out and test your Flow the ‘old’ way and then if you want to use the new Record trigger you have to clone the Flow, change the trigger type and then replace all the references to the trigger variable with the new variable automatically created via the record that now triggers the Flow. It seems like a lot of extra work for very little reward so, for the time being at least, it’s best to stick to tried and tested methods until the Debug feature is added to the Record-Triggered Flow type.

--

--

Rob Clough

2x Certified Salesforce Administrator working in RevOps and sharing code free Salesforce apps; focussing on Flow and minimum viable product design principles