.png)
.png)
Last time we talked about the reasons you should involve code in your flow – for this blog, our focus will be on a deeper dive into some great examples of where this is helpful, what they provide, and how they are designed to be flexible.
Hopefully, this should give you insight into what to ask for if you’re discussing Custom Flow Actions with a developer or considering creating some yourself.
The actions that will be a focus for this blog are the ones I use most commonly to solve regular gaps in Flow and Salesforce functionality. ‘Navigate Everywhere’, ‘Send HTML Email’ and ‘Show Toast’.
Alone, none of these are make or break, but between them, they can elevate simple flows into something a lot more polished and provide a lot of value.
The other important thing to keep in mind is the difference between what the Flow is achieving and what the actions are set up to achieve.
Hopefully, when we get to the end of this post – the benefits of this approach will be clear.
For this to (really) make sense – we will need an example, so we’ll take one I’ve seen a few times now: Call scripts. When an outbound agent is making a call, they went things to be as easy as possible.
Flow is a natural choice to guide a user through a call ‘flow’ as it can take different paths based on input but can also handle situations where the call is ended early, or a voicemail is left.
They can also use screen components (though not the subject of today's blog!) to make important text or actions visible without cramping the agent’s style, so there’s still some personal elements to the call.
The first Action to focus on is ‘navigate everywhere’. This is an amazingly simple but incredibly powerful action that allows you to open new service tabs, or browser windows and point a User to any record or webpage that you may need. Its simple and quick to set up and can cope with pretty much any situation.
The standout areas I want to focus on here are the inputs. They are simple and named in a clear and self-explanatory way. This is what gives the component so much flex (and why you should install it in any org where you’ll be using Screen Flows).
Not only can you open record pages, but you can also open them in either edit or view, allowing your user to get to exactly the record they need in the state that is most helpful.
So, looking back at our call centre – this means if a Case comes up – we can send the User straight there. If, once the call is done, the User should go and edit the Contact record based on their findings, they can be there.
We can take the end-user to the right part of their Business Process with minimum effort, and from experience, it’s the little things like this that really help adoption and success.
The send email action is similar – having many inputs, but all clearly named, allowing the component to flex to pretty much any situation.
Email alerts are usable in Flows providing the most basic of email sending that requires a template and an alert to be set up as is. However, this can be fiddly and time-consuming, as well as the biggest limitation of all – Activity History.
Simply put – email alerts don’t post to history or create any record that they happened at all. Which for our call centre logging outbound calls, just isn’t up to scratch.
This is where the send email action comes in.
This action gives us a lot of choices – we can choose when to save or not save email activity (useful for internal notifications that don’t need to be logged).
Pick what template (if any) to use, by both Name and Id (great for sandboxing and not hardcoding!) and even who the email should be coming from. This gives us the power to work with pretty much any situation that can come up, as well as being user friendly.
This is a great example of how instead of solving the immediate issue ‘I want to send an email that has activity logged against my recipient’ the designer has solved a bigger issue – ‘ I want to send emails to one or many people from Flow – and I may/may not have a template or activity’.
This goes back to the concept we mentioned at the start - building something once and repurposing as needed. This can be dropped in any Flow in any Org and can add value.
Lastly, the most simple of all the actions, Show Toast. Toasts, for the uninitiated, are the little green, grey and/or red boxes that appear at the top of the screen when an action is completed.
From my perspective, I only notice these if they are missing. They tell the User when something is right or wrong – and can link to records that have been created. Much like the Navigate Everywhere actions, these help your User understand what is happening, or identify an issue.
To take all of this back to our example – let’s say the end-user hits voicemail – they can send email from the Flow informing the contact of a missed call, have that logged as an activity, provide confirmation to our User that this has happened with a green toast, and then send the User to the Contacts record so that they can look for alternative Contact information.
This is a slick experience – and we’ve still used a configurable approach – it just happens to include code to assist us. Myself as the administrator creating this, however, has not had to touch code at all.
We should be seeing a common theme now – simple to set up, reusable and able to provide a slick experience which provides clarity and directs the end-user. We as administrators lose no control through doing this, and developers only must make a component or action once, if they take this mindset.
At the end of the day, the goal with any Screen Flow, or component within one, should be to get it to look, feel and act like Salesforce.
