Lightning Flow is excellent tool that empowers any business to create and extend the power of process automation to any customer or employee experience. We can leverage 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 requirement. We have to manage flow in better way so that it will be easy to maintain and offer better performance.
Let us see top 10 best practice for lightning flow which should be implemented while creating flow.
1. Naming Guidelines
We should use proper name of flow and its element. As now we have unlocked package as well so we should name our flow based on module being developed so that it can be used easily in module package.
Flow Name :
Flow API name should indicate module name and what is use of that flow. Let us take example we are working for vendor management system and module is related to document generation. In this document generation module, we need to create screen flow to manage document. So we can put flow api name like VMDG_ManageDocument.
Variable Name: Variable name should be based on type of variable, no of values it can hold and use of variable eg. customerName or customerNames or customerList.
I personally not prefer putting prefix to identify type of variable instead variable name should indicate type of variable like instead of putting strCustomerName we can put simply customerName.
2. Flow and Sub-flow
Lightning Flow is now more powerful then process builder, workflow and trigger. We can create multiple flow on same object but it will be difficult to manage those flow. To manage those flow we can create one main flow and based on decision elements we can call other sub flows. Each flow should create for seprate business logic so that it can be used by other flow as well. Similar to method call in OOPS concepts.
3. Multiple trigger Flow
As we can create multiple record trigger flow, but it will be difficult to manage those multiple flows. Better we can create two trigger flow for each object, one for before save operation and one for after save operation. In those before and after trigger flow, 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 SOQL limit exception error. Create list variable and add single variable in that list and update/insert it at last.
5. Error Logging
We should log error for each failure. Try to log each error in 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 Get Records operation, if data not found then return null and use decision element on that variable. If result is not null then do first activity otherwise do other activity based on user requirement.
7. Test Flow with user
If you are not getting proper result while testing flow then try to debug flow with user who will use it. Add all permission set on user which will be applied in application, so that you can properly analyze issue. This is one of good feature to test flow functionality.
8. Test Performance of flow
Always get flow tested for multiple users simultaneously, specially if flow is working for multiple records at a time. It will help us in identifying performance issue, SOQL timeout issue and SOQL query limit issue.
9. Never hardcode variables
Always pass data at runtime to flow. Don’t hardcode in flow variable like if we need to pass current record id then pass it from other flow or from app builder page. Even any static variable is required then try to put that in custom setting/metadata type so that it is tested as configurable values.
10. Create document of Flow
Document each flow use case to maintain it properly. As number of flows will increase so it will be difficult to know which flow will do what. Document will help 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
