scheduled flows + visualforce email templates

Many options exist to notify folks about salesforce data. I classify them as ‘popcorn’ (email alerts / chatter posts / notifications via workflows/flows/processes) or ‘consolidated’ (report subscriptions, that random opportunity email thing, custom visualforce emails with summarized info).

HR needed to automatically notify managers when people who reported to them had a contract that would expire in 90 days. Report subscriptions dont scale for this. Popcorn is a pain to build, and makes for a fractured user experience, so I wanted to send the manage a single summary email w all the data, on the first of the month.

The full-code way would be a scheduled batch job that sends the email, which can be all code. Nothing crazy, but i would guess a hundred lines or so,

Instead, I used scheduled flows and a visualforce email template in a regular old email alert, which leaves most of the logic and sending apparatus low code. You do need a custom vf component in order to sort the data in the email, which is likely something you want to do, but is still maybe a dozen lines of code in total.

The basic approach was as follows

Checkbox formula field on the employment record - the one with the end date - determines which ones were within 90 days of today. Ensures that the custom component and the flow to use the same filter logic, and also helps in case the logic is more complex than what you can do in a get records element.

The employment record contains the manager ID (lookup). Scheduled flow gets all ‘flagged’ employment records and iterates over them to create a unique collection of manager Ids. This uses a little trick to create a unique collection in flows - remove all values and then add one back.

The scheduled flow then loops over the unique collection of manager Ids, and passes the Id into an email alert action in a loop. *ok yes this is not bulkified - and if you have thousands of contract employees, you prob have developers on staff and can get them to wire up that batch job. that said, i dont understand scheduled flow bulkification well enough to know exactly when it would hit the limits. the 2,000 iteration limit is probably what will give out first, so keep that in mind. we send about 100 emails per batch, so maybe 150 contractors in total.

On the vf email alert, relatedTo = the ‘team member’ object (the managerId is a team member record). The managerId passes to the component which uses it to render a table of the contractors who report to the manager.

Some quirks and notes
a) For reasons unknown, I had to add the renderUsingSystemContextWithoutSharing="True" attribute as otherwise the automated process user could not see some of the custom fields. Not sure if this was an issue related to the managed package that this data is coming from, or what. But thankfully that fixed it as without that it was a real mess and I was out of ideas.

b) I had to use this url hack to give the automated process user access to the apex controller for the vf template, else you get the error

core.email.template.TemplateRenderingException: system.security.NoAccessException: You do not have sufficient privileges to access the controller:

c) you must set the Automated Process User Email Address in process automation settings to allow the automated process user to send email alerts

d) i also used a url hack to grant field level security to the automated process user for fields used on the email template whens i was running into issues w fields not displaying on the email. i think renderUsingSystemContextWithoutSharing resolved it, and this was not required.

For a demo i have mocked this up on opps, to build a customized ‘opportunity reminder’ that will send a list of open opps to the opp owner. You could modify this to send account owners a list of all the open opps on their accounts. Lots of possibilities.

Yes it requires code. But not a lot!

On to the demo…

 
95
Kudos
 
95
Kudos

Now read this

Preventing duplicate junction object records

Native dupe management only allows you to reference a single lookup field. So it cannot prevent duplicate junction object records. By using a (new in spring 20) before save flow to concatenate the two IDs into a single text field, you... Continue →