Lightning Flow is an excellent tool that empowers any business to create and extend the power of process automation to any customer or employee experience. We can leverage the power of low-code, drag-and-drop functionality to customer engagement, Lightning Flow delivers an innovative new way for businesses to realize the benefits of process automation. As number of flows will increase based on project requirements. We have to manage flow in a better way so that it will be easy to maintain and offer better performance. Let us see the top 10 best practices for lightning flow that should be implemented while creating flow.
1. Naming Guidelines
We should use the proper name of flow and its element. As of now we have an unlocked package as well so we should name our flow based on the module being developed so that it can be used easily in the module package.
Flow Name :
Flow API name should indicate the module name and what is use of that flow. Let us take an example we are working on a vendor management system and the module is related to document generation. In this document generation module, we need to create a screen flow to manage documents. So we can put a flow API name like VMDG_ManageDocument.
Variable Name: Variable name should be based on the type of variable, how many values it can hold and the use of the variable eg. customerName or customerNames or customerList.
I personally do not prefer putting prefixes to identify the type of variable instead variable name should indicate the type of variable instead of putting strCustomerName we can put simply customerName.
2. Flow and Sub-flow
Lightning Flow is now more powerful than process builder, workflow and trigger. We can create multiple flows on the same object but it will be difficult to manage those flows. To manage those flows we can create one main flow and based on decision elements we can call other sub-flows. Each flow should be created for separate business logic so that it can be used by other flows as well. Similar to method calls in OOPS concepts.
3. Multiple trigger Flow
As we can create multiple record trigger flows, but it will be difficult to manage those multiple flows. Better we can create two trigger flow for each object, one for before the save operation and one for after save operation. In those before and after trigger flows, we can create decision elements and based on decision result we can call sub flows.
Naming Convention for record trigger flow– {ObjectName}{eventoccurance}Save like AccountBeforeSave, AccountAfterSave
4. Bulkification
Similar to Apex, we should always use bulkification wherever we can apply that otherwise we will get an SOQL limit exception error. Create a list variable and add a single variable in that list and update/insert it at last.
5. Error Logging
We should log an error for each failure. Try to log each error in the custom object using Platform Event. When we are doing DML operation at that time, if any issue in operation then log that error. Refer help document for handling fault exception.
6. Null handling and Branching
While retrieving records using the Get Records operation, if data is not found then return null and use the decision element on that variable. If the result is not null then do the first activity otherwise do another activity based on user requirements.
7. Test Flow with the user
If you are not getting proper results while testing the flow then try to debug the flow with the user who will use it. Add all permission sets on the user which will be applied in the application, so that you can properly analyze the issue. This is one of the good features to test flow functionality.
8. Test the Performance of the flow
Always get flow tested for multiple users simultaneously, especially if flow is working for multiple records at a time. It will help us in identifying performance issues, SOQL timeout issues and SOQL query limit issues.
9. Never hardcode variables
Always pass data at runtime to flow. Don’t hardcode in flow variables like if we need to pass the current record id then pass it from another flow or from the app builder page. Even if any static variable is required then try to put that in the custom setting/metadata type so that it is tested as configurable values.
10. Create a document on Flow
Document each flow use case to maintain it properly. As the number of flows will increase so it will be difficult to know which flow will do what. The document will help the developer to easily change in case of requirement change or addition.
References:
https://help.salesforce.com/articleView?id=flow_build_logic_fault.htm&type=5
https://help.salesforce.com/articleView?id=flow_builder.htm&type=5
