1. Naming Guidelines:-
We should use the proper name of flow and its element. As of now, we have unlocked the 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 module name and what is the use for that flow. Let us take an example we are working for the 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 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 do not prefer putting prefix to identify the type of variable instead variable name should indicate the type of variable like 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 create for separate business logic so that it can be used by other flow as well. Similar to a 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 saving operation and one for after saving operation. In those before and after trigger flow, we can create decision elements, and based on decision results 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 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 is in operation then logs 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 other activities based on user requirements.
7. Test Flow with user
If you are not getting proper results while testing flow then try to debug flow with the user who will use it. Add all permission set 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 Performance of flow
Always get flow tested for multiple users simultaneously, especially if the 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 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 a document of Flow
Document each flow use case to maintain it properly. As the number of flows will increases so it will be difficult to know which flow will do what. The document will help developers to easily change in case of requirement change or addition.