Salesforce have shared a plan to retire Workflows/Process builder in future. Salesforce has built a tool to convert PB and Workflows to flows but it can not convert all type of logic present in Workflows/Process builders. If your org is old and complex ,then by no mean you can rely completely on the salesforce conversion tools . Don’t Jump the gun for this activity as this can be as complex as it gets. Treat this work as a tech debt project and do a detailed analysis of the existing WF/PBs , it is worth to analyze and then slowly convert these to the flows.
Why it is important to take time to do analysis of the existing WF/PB?
Don’t waste this valuable opportunity to do a “Lift and Shift” of logic from WF/PB to flows. Make sure you get rid of any unused logic/action , consolidate redundant/related logic. Make sure you make the logic simpler.
Things to keep in mind
- Sequence of execution of different automation tools in a transaction. This will help you to find out what type of automation tool will be the new place for the logic from WF/PB. you can find the sequence of execution here https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm
- There will be certain situation where you have to move the logic from PB/WF to ‘before triggers’ instead of flows. Dependency of an action present in WF/PB on other actions in the same transaction. eg: If there is field update in the ‘before triggers’ and then the value of the field is used to do an action in a workflow.
- Dependency of workflow action on a workflow field update by the use of “Re-evaluate Workflow Rules after Field Change“
- Determine the correct type of flow for a use case. Don’t put a field update in an ‘after save’ flow , ‘before save’ flow is optimized for field updates.
- Number of flows per object. Ideally, you should create only one before save(create or update) flow , one after save(create or update) flow & one delete flow per object but this is not realistic if you have lot of logic to be built for the object. Start with these 3 flows and then add new flows if required. Define some guidelines for your org , on when to go for a new flow instead of modifying the existing one for a use case. eg: if a flow becomes huge then it make sense to create a new one or split the existing one as it is hard to manage a huge flow. If an object is heavily used across different business function , then you can create a flow per business function.
- The workflows/triggers may have redundancy/related codes , consider consolidation of the logic.
- Flow best practices to achieve maximum performance gain.
- Dependency on recursion caused by Process builder field updates.
- Here is the retirement plan for Workflows/Process Builders https://www.salesforceben.com/salesforce-to-retire-workflow-rules-and-process-builder/