Salesforce Flow Examples + 8 Top Tips
Salesforce Flows are a way to automate processes using a point and click interface without the need for code.
With each Salesforce release, Salesforce Flows get better with new and exciting features being added. The last few releases have seen tons of new features such as Columns, Record Triggered Flows, Auto Layout, and the long-awaited ISCHANGED() functionality.
As a Salesforce Consultant and Answers leader, I truly love Flows because most of the time they can do the job using clicks, not code. Administrator(s) can maintain them, which is another bonus, reducing the need to revert to a Developer every time a change is required.
This post will run through the set of rules I stick to that are inspired by Salesforce best practice, and then share some use cases you can apply Flows to, for some real-life “Flowspiration”!
If you’re looking for an introduction to Flow, read this guide.
Top Tips for Salesforce Flows
When building Flows, I stick to a set of rules that are inspired by Salesforce best practice:
1. Do not hard code IDs.
Salesforce IDs are unique to a specific org for the most part and as such should not be referenced directly. Instead, use a ‘Get Records’ component to dynamically find the necessary record and then use the returned ID.
2. For Email Alerts make sure the email field is populated.
If a Flow tries to send an email using an email field that is blank it will error. Make sure you include a condition to only send an email if the email field is populated.
3. Make sure Users are active.
If you are changing the owner of a record to an inactive user you’ll likely get an error. To prevent this from happening, try not to reference specific users or make sure the user is active before you make record updates.
4. Build Error Paths.
If you have lots of Flow Elements this may be a pain however, in the long run, error paths help users with a customised error screen that uses language they are familiar with rather than a nasty red indecipherable error message!
5. Do not Loop the Loop.
It’s best practice to avoid Get Records or Update Records Elements in Flow Loops. This is to ensure your Flow stays within the limits that Salesforce has in place to safeguard system integrity and performance. If you really need to do this then ‘bulkify’ your solution (source).
6. One Automation per Object.
Where possible have one process builder or one Flow per object. Imagine having 50+ automations on the Lead Object; you could spend hours trying to figure out what is going wrong. Long term this makes your solution more maintainable.
7. Do not build straight in Production.
If you build a Flow in the live environment and this starts to go wrong it could cause irreversible damage (if you don’t run in rollback mode). Build in a Sandbox first and test as many scenarios as possible before making changes live.
8. Using Component Visibility to your advantage.
If you are displaying information from a Related Record on the Flow Screen then using Component Visibility only displays fields that are populated instead of showing blank fields!
Some real-life Flowspiriation
From my own experience I’ve seen the good, the bad and the ugly when it comes to Flows. Here are some of my top picks of the good:
Record Triggered Flow to Count Opportunity Contact Roles
Using tools such as Pardot, it’s imperative that you use Contact Roles with Opportunities, in order to report and automate effectively.
With a simple Record Triggered Flow on the Opportunity Contact Role object, you can count the number of Contact Roles and even stop the Opportunity being progressed to the next stage (with a validation rule) if there aren’t any related contacts.
You could opt for a softer approach with a warning message on the Lightning Page if your count field was 0.
Record Triggered Flow to Update Case Status on Chatter Post
What if you want a Case status to update should a Customer add a chatter post in your Digital Experience Site?
Using a Flow related to the Feed Item Object, you can achieve this in a few clicks and create a solution that can be easily tweaked should you need to in the future!
Record Triggered Flow to Stop Duplicate Records
If you are scared by the prospect of using a VLOOKUP type validation rule to prevent duplicates or wouldn’t know where to start, how about using a Flow instead?
When a Record is Created or Edited you can use a Get Record Element with criteria to find duplicates and then throw an error message or perform an action to alert someone of the duplicate.
Screen Flow to show a Customer/Partner User their Support Entitlement/Contact Person
A few releases back Salesforce added the functionality to hide the footer and the header from the Flow screen.
This means you can now sneakily embed a Flow on a page without the users even knowing they are using Flow.
I’ve used this a few times to:
- Display the Customer’s Account Support Level in a card-like format
- Display the Partner’s Contact Person details, with their picture to personalise service
Summary
Like all systems, there are limitations with Flows such as issues with Owner fields on Screen Flows and difficulties with parsing Multi-Select Picklist Values that it would be nice for Salesforce to resolve longer term.
However, I’m still very excited about Flows and what’s to come as from the last few releases there are pages of new features with more each release.
Salesforce is heavily investing in Flow with a goal of making this even easier to use in the future so if the prospect of a Flow is daunting don’t be scared and dip your toe in your Trailhead Modules to help you get started.
Let’s go with the f-l-o-w!
Ian Gotts
Can I suggest Top Tip #1 is Document it because when you come back you won’t remember the nuances. So documentation can be automated by apps that do where used. But the overall logic is best captured as a process diagram
Hendrik
Thanks for this great article! Question Re Tip #6 „One Automation per Object“: with Process builder this seemed to be easily doable (multiple entry criteria etc.) however we struggle to follow this best practice esp. with the new „record triggered flows“. Would you suggest to have only one record triggered flow as well, trigger it everytime a record is created or changed without conditions and then build all the logic into process-builder-style „Entry criteria“ with multiple decision elements within the flow?
Brandon Heise
In general, I follow the one process or flow per object rule when possible (particularly when order of operations control is necessary). That said, here’s something to consider. Are your object’s records created/updated only by users or also by batched integrations or file loads? If the records are created/updated by batched integrations or file loads you may find that you hit CPU limits and the flow fails to run for some records depending on complexity of the process/flow and number of records per batch. I’m busy rebuilding one-per-object Process Builders and breaking them up into narrowly scoped Flows for this reason.
Aske Bong-Saxe
Great article, thank you Tom. However, I respectfully disagree with tip #6, at least as a general rule. We used to follow this design pattern when working with Process Builder, and it made sense at the time. But because of how entry conditions works in Flow, it means you can control whether a flow is loaded into memory or not, similarly to how Apex works. Therefore it doesn’t make sense to me to make a single large flow that will trigger every time a record is created or deleted. Instead, I prefer to use entry conditions to control whether a flow is triggered or not. It’s effectively the same reason why developers don’t write a single large Apex class per object. Instead they compartmentalise the code so that the platform doesn’t need to execute all the code for every record. This can be particularly important in Large Data Volume orgs. In my organisation we therefore design record-triggered flows with an approach that is analogous to how workflow rules were designed.
Jingli
Hi Ben,
Salesforce keep enhance flow a lot in every recent releases. do you have any latest flow best practices based on the 22 winter release? especially like one trigger/process builder on one object, should we consider one flow(record trigger flow) on one object as well? since we have many record types in some objects and different team working on specific record type, so I think we should recommend to utilize subflow on each record type and main flow to check on record type and call subflow so that the developer from different team will not overwrite other team’s subflow. but if we do consider to use one flow one object, then the entry criteria on the main flow has to be very general or nothing. but that will cause all records update/create/update will trigger flow. any recommendations will be well appreciated. Thanks.
Arun
Email to case scenario
When email sent customer1 case is created.
After when the case is closed, an email has to send to customer1 (case is closed).
If the customer1 replies to the send email again case should be reopened.
I have done using flows and process builder using 2 files(i.e., PB/Flows).
1) Sending email using Case object
2) After email replies get Updating the case using EmailMessage object.
But I am trying to done these two using one flow (using EmailMessage).
Condition flow
I) Incoming mail
A) Yes: Case is close update the record.
B) No: Do Nothing.
C) Else: Send an email that case is closed.
Tom Bassett
Hello,
If you are after guided support please post on the Trailblazer Community here;
https://trailhead.salesforce.com/trailblazer-community/
Since the article was written Salesforce have updated best practices and it’s no longer ‘best practice’ to have one automation per object as this is depends on business processes and there is now the Flow Trigger Explorer to control the order of execution.
Thanks Tom