Salesforce Flow Best Practices : Amit Chaudhary
by: Amit Chaudhary
blow post content copied from Apex Hours
click here to view original post
After a big announcement in Dreamforce 2021 that Process builder will be deprecated in 2023. Now Salesforce flow is future of automation tool. Salesforce Flow is the most powerful declarative automation tool that Salesforce has built. We all know that “with great power comes with great responsibility”. So, it’s important to learn about Salesforce Flow best practices and Salesforce Flow Design Patterns (what TO do and what NOT to do in Flow).
Here are 10 Salesforce Flow best practices that we talk about in our session Salesforce Flow Design Patterns. A design captures underlying thought process and logic on which a flow is built. As a result, there is a strong correlation between a robust design and a powerful process. In this blog, we’ll discuss best practices, ‘gotchas,’ and design tips to make sure your flows scale with your organization.
1. Always! Plan Before You Build
The key to successful project implementation is – design first and then implement. Salesforce Flow is no different – the same logic applies here too. I have seen many cases where people start creating Flow(s) as soon as they get requirements. As a result, more often than not, users end-up getting some weird error messages.
Business Case: Steven Greene, a Lead System Administrator at Universal Containers(UC), received a requirement to create an automation that would allow System Administrator to quickly create users by cloning an existing user including public group, queue memberships and associated permission sets.
2. “One Record-Triggered Flow” Per Object – Per Type
Once you understand the requirement and create a flow diagram, do not rush to implement it by creating a new Flow. Try to find an existing Flow and see if you can incorporate current requirement(s). Furthermore, to achieve flexibility and create reusable Flows (subflow). Following, one record-triggered Flow per object, concept will allow you to manage all your flows for a given object in one place.
For, when you have one flow per object, it is less likely to hit limits such as number of SOQL queries; and, it will also allow you to avoid generating infinite loops.
Learn more here.
3. No DML Statement in Loops
Never performing a repetitive Get, Update, Create, or Delete inside of a Loop. Similar to Apex, we should always use bulkification wherever we can apply that otherwise we will get SOQL limit exception error.
If you have a collection of many records, and you perform an update to each one within the loop, you’re at risk of hitting DML limits. If you’ve ever received this message.
Error Occurred During Flow: Too many DML statements: 151Create list variable and add single variable in that list and update/insert it at last.
4. Use the Advanced Technique to Merge Decision Node
Once you start thinking about one process per object – you may wonder, how can I handle process/action which needs to be fired only at the time of creation? The answer is very simple – use formula ISNEW() while defining the criteria! Similarly, if some automation applies only to cloned records, then use ISCLONE() function.
5. Build Reusable Flow(s) – Subflow(s)
Subflows are a sequence of reusable actions to use in a flow. You can create subflows to perform common processes specific to a custom application.
Subflows consist of:
- Subflow inputs to pass variables to the actions in the subflow.
- A sequence of actions, flow logic, and subflows.
- Subflow outputs to create data (variables) for use by other flow actions or subflows.
- Subflow is an Autolaunched Flow.
6. Don’t Create Flow for Everything
If it is possible to achieve a solution through Formula or a Report then, don’t create automation for it!
Basically, use automation sparingly!! For example, if you want to display Account Site on Contact record then use Formula field, not a Record-triggered Flow.
At the same time, if there is something that can be better handled through Apex Trigger use them, like handle duplicate platform event in same transaction
7. Build in a test/Sandbox environment
Processes can be created or updated in a production environment – I have seen people make changes directly into production org – don’t!
Without testing into development, creating or editing in production environment ‘may’ (read, certainly will!) lead to data loss or trigger some unwanted emails or end-up creating too many test records.
8. Supercharge Flow with Invocable Apex
•Flow Builder comes with a lot of functionality, but sometimes your flow needs to do more than the default elements allow. In that case, call an Apex class from your flow by using an Apex action. For example, •Generate Quote PDF • Find list of Opportunities by passing Account Ids
Define your invocable methods in Apex with the @InvocableMethod annotation
- Limit 1x @InvocableMethod annotation per Apex class
- Supported unputs/outputs: Primitives, SObjects, Apex-defined classes, lists
- Must be bulk safe. Input and output are always lists.
9. Don’t Hardcode IDs, Query for them!
So what next? How to avoid Hard coding of IDs in Flows? Some of the ways to avoid hard-coding are as follows
- Use Get Records to Query them
- Use Custom Label to store Id
- Use Custom Metadata Types to stores Ids
10. Dont mix Trigger, Process Builder, Flow and Record Trigger Flow.
Every object should have an automation strategy based on the needs of the business and the Salesforce team supporting it. In general, you should choose one automation tool per object. One of the many inevitable scenarios of older orgs is to have Apex triggers mix in with Autolaunched flows/processes or, more recently, Process Builders mixed in with Record-Triggered flows. This can lead to a variety of issues:
- Poor performance
- Unexpected results due to the inability to control the order of operations in the ‘stack’
- Increase in technical debt with admins/devs not collaborating
- Documentation debt
One common approach is to separate DML activity and offload it to Apex, and let declarative tools handle non-DML activities like email alerts and in-app alerts — just be careful and ensure none of your Apex conflicts. We’re still very much in the ‘wild wild west’ phase of Record-Triggered flows as architects and admins figure out the best way to incorporate them into their systems.
Check out this Apexhours session to understand the performance consideration for different automation tools.
11. Handle Errors with Fault Paths
From time-to-time, things don’t work out exactly as you expected in your flow — that’s where error handling comes in. With error handling, you can define any number of steps to run after the failure of an action.
If your flow contains an element that interacts with the Salesforce database—such as an Update Records element or Create Records element – it can fail. You can modify the default behavior by adding fault paths to all elements that can fail.
- Show customized error message for Screen Flow
- Send an email alert containing error message to a group of people
12. Exception handling in flow using Platform Events
What about if you want to fail the complete transaction? But we have seen that we have a fault connector – transaction will be a success.
Check this post to learn about Salesforce flow using fault connectors and Platform events framework.
13. Use Debug Log to Check Why a Flow Fails at Runtime
However, with great power comes great responsibility. If a user starts creating a new flow for each requirement – or creating flows without understanding Salesforce limitations – then, a user may encounter many issues, either in future or, while testing/deployment phase.
Now once you encounter the error message don’t be panic – you are not the only one who has ever gotten error messages; and this may be your first but, it certainly will not be the last time you encounter an error message! So, the best thing to do is to learn how to tackle it!
14. Document your flows
Documenting your flow allows the next person, or the forgetful future version of yourself, to understand the overall flow’s objective. Flow designers don’t create solutions out of thin air — we need a business case to solve hard problems, and having those breadcrumbs is critical for maintaining the automation long term.
15. Flow Naming Conventions
Follow Salesforce flow naming conventions while designing the flow in Salesforce.
Check our ApexHours session recording here
If you are new to Salesforce flow then check our FREE Salesforce Flow Training here.
Create a Checklist for Flow Builder
- Documented elements and descriptions
- Null/Empty checks
- No Hard-coded IDs
- Avoid nested loops
- avoid Looping over large data volumes
- Check record and field security & flow context
- No DML in a loop
- Flow errors
- Automation bypass by custom metadata.
Summary
Flows are a wonderful way to create automation within your Salesforce org. So it very important to follow the Salesforce best practices to avoid governor limit and design pattern help you to make you configuration as per your company standards.
The post Salesforce Flow Best Practices appeared first on Apex Hours.
November 22, 2021 at 05:30PM
Click here for more details...
=============================
The original post is available in Apex Hours by Amit Chaudhary
this post has been published as it is through automation. Automation script brings all the top bloggers post under a single umbrella.
The purpose of this blog, Follow the top Salesforce bloggers and collect all blogs in a single place through automation.
============================
Post a Comment