How to analyze, plan and prioritize your Flow migrations

A lot has been written in blogs about how to build Flows and exploit the capabilities. There have also been articles on how to migrate to Flow that are teaching you how to build great flows.   i.e. how to cut down trees. This article is about how you analyze, plan and prioritize your Flow migrations.  i.e. are you in the right forest?

FLOW IS THE FUTURE

There are many Salesforce automation tools and it was always a challenge to know which one to use in which situation. That has gotten so much easier. Now there is only one: Flow. Flow is where the Salesforce investment is going, and Salesforce is putting a lot of effort into helping organizations move from Workflow Rules and Process Builder Workflows (PBW) to Flow. BTW we are going to call Workflow Rules and Process Builder Workflows collectively “legacy automations” for the rest of this article. Will also include existing Flows in “legacy automations” as then may be able to be consolidated or extended. 

There is no end of life or burning platform announced, but Flow is going to be the go-to automation platform so it is where your learning and development should be focused. 

But don’t be fooled into thinking that this is a simple migration from one WFR or one PBW to one Flow. In the simplest of cases, it could be. But for any enterprise org, there will be the chance to merge and simplify automations. Not taking advantage of this is a huge missed opportunity. An opportunity to take advantage of Flow features. An opportunity to clean up tech debt. An opportunity to simplify, rethink and combine automation. 

Hence the title of this article, “Don’t migrate to Flow. Refactor and move to Flow.”

BUILDING A BUSINESS CASE

As we said, Salesforce is not going to end the life of other automation tools in the short term. But they are going to be putting all their investment into Flow as THE automation tool. And Flow has so much more automation capabilities than the other declarative tools. But it also enables you to get out of the more limited “if, then” Process Builder way of thinking and approach problems with a true automation mindset.

Any change to Salesforce is going to require analysis and development work. Don’t jump into building Flows. You’ll probably regret it and end up in OrgConfessions.com. So you will need to build a business case. There may not be a case to move every legacy automation to Flow, initially. You need to develop a strategy to prioritize the changes. It is never going to be simply “run this migration tool”. 

Some of the business benefits of moving to Flow, in order of business value

• Redesign automation based on current business needs
• Simplify by consolidating multiple automations into one Flow
• Reduce the need to code with more powerful declarative automation 
• Reduce maintenance effort by moving from code to low code 
• Remove tech debt in legacy automations that will be moved
• Delete unused legacy automations
• Develop faster by exploiting future flow features 
• Reduce training as there is only one automation technology

ANALYZE, PLAN & PRIORITIZE

Making any changes to Salesforce creates risk, especially if the org metadata configuration, impact and dependencies are not well understood. Unpicking legacy automations to understand which can be deleted and which need to be combined is time consuming, especially if there is limited documentation. 

At Elements.cloud, a junior admin moved 2 Workflow and 50 PBW to 45 Flows in just 2 days. We estimated it would take 30 days, but as the business processes and metadata were so well documented it was so much faster. BTW that junior admin didn’t even know how to spell Salesforce 6 weeks ago, but access to training and support from Senior Salesforce Admin meant he did the job perfectly.  

Capture current automation requirements

Any refactoring needs to start with mapping and understanding the business processes. If they are already documented, then you can use them to review the legacy automations with the business users. If they do not exist, then this is the perfect opportunity to run interactive workshops with the business users to drive out improvements and at the same time validate the automation requirements. 

The Salesforce standard for process mapping is called UPN (Universal Process Notation). There are training courses (Trailhead and Architect) and Elements.cloud supports the UPN standard.  

https://trailhead.salesforce.com/en/content/learn/modules/business-process-mapping

https://academy.elements.cloud/courses/process/

Understand your Org legacy automations

Then you need to analyze the current legacy automations in the context of the business processes that have been mapped. This analysis looks at them to understand what needs to be moved to Flow and an idea of the priority. Here are some of the factors

• Clear the dead wood: Delete never used and unused
• What is heavily used, but could be more efficient: Opportunity to consolidate, simplify and optimize
• What is complex and scary, but needs to be fixed: Opportunity to reduce tech debt

The suggestion is to go object by object rather than get overwhelmed by the huge list of legacy automations. The primary objects are likely to be Opportunity and Case. Then Lead, Account and Contact. But the org discovery described below will help you understand the scope of the problem.

The slight challenge is that PBW are all listed together with Flow in Salesforce Setup, with no indication of which objects they impact.  But it is significantly easier with a metadata dictionary where automations are shown in the context of the object. 

Org discovery with metadata dictionary

To support the org analysis you need to build a metadata dictionary which pulls in all the metadata, builds documentation and identifies the interdependencies. That will save days or weeks of work as many (or most) orgs have limited documentation.

Having a metadata dictionary means you have all the information in one place and the org analysis done for you. As you decide what to do with each legacy automation you may need to look at lots of different but related automations and metadata, So use the metadata dictionary to document your findings and actions as you go along.

Here is an example of a metadata dictionary advanced functionality – the dependency tree. In the left panel it shows the dependency of a metadata item down multiple levels. The right panel shows the automated documentation for the selected metadata, but also allows you to add actions, enter notes, link to the process maps, 3rd party documentation or photos / screenshots.

There are actually 19 different insights shown in this one view. Don’t believe me?  Here are all 19 listed out  https://elements.cloud/2022/01/20/how-many-insights-can-you-count/

ANALYSIS DONE. NOW BUILD.

Flow is extremely powerful and will get even more powerful with every Salesforce release. This is an opportunity to understand the org, refactor the automation and clean up tech debt. So, when you build the new Flows make sure you follow some standards so that they are easy to maintain and improve. Bear in mind that there may be a number of different people building Flows so you want everyone to have guidelines. As the famous Pirelli tire ad said “Power is nothing without control” Or as Spider-Man said, “With great power comes great responsibility”.

Here are some of the standards that you should put in place before you start building

• Naming standards; Think of the future you coming back to this after 6 months. How will you find the right flow when you could have 100’s? How will you be able to quickly understand what the flow does?
• Architecting flows; You need to think like a developer not a configurer. And you need to consider maintainability. There are some established principles, such as one Flow per entry criteria rather than object, simplify with invoked actions, split out reused logic into sub-Flows, and do not hard code IDs. Here is the ultimate best practices guide written by Salesforce.
• UX; What are your design patterns? Using similar layouts and terminology will accelerate adoption. Consider taking the UX Designer certs. 
• Testing; Flow is very powerful and unpicking data that was changed due to bugs is very difficult and time consuming. So testing is paramount. So what are the testing approaches and standards? What is the minimum testing to be able to deploy? ​​Jest is an emerging testing framework.
• Stakeholders; Who is the owner, who needs to be consulted, informed, before it is changed and who authorizes the changes?
• Documentation; This is at a number of levels. What is the high level description? How are you going to document the overall process and link it to the business processes. Think about “Why” you created the flow, “What” the flow does” and then “How the flow is structured. Finally, the relationships to other metadata which may be external systems. You probably need to link to an ERD or the objects impacted.
• DevOps; You need to define the changes as Work Items or User Stories. Then you can drive the changes through a release pipeline. Changes should be made in a Sandbox, not Production. You should have a different DevOps process for low risk, simple changes and another for complex, high risk changes. This enables you to get low-risk changes out more quickly with less effort. But also think about what else needs to be released at the same time – other Salesforce metadata changes, other apps that are integrated, and training content.

THE FINAL WORD

Salesforce is investing in Flow as THE single automation tool on the platform. They are providing training, tools and support to strongly encourage migration from Workflow Rules, Apex Triggers and Process Builder Workflows to Flow. This is not really a migration as it is not one-for-one and it is certainly not a simple “push a button”. Where there is change there is risk, but also opportunity. Opportunity to take advantage of Flow features. Opportunity to clean up tech debt. Opportunity to simplify, rethink and combine automation. There are tools to make this easier, quicker and safer. This can make it stress-free and a big win.

 

NEXT STEPS

Contact us to find out more about using Elements.

• Customers elements.cloud./bookdemo
• Consultants & ISV elements.cloud/booksi

This article was based on input from Flow experts:  Tim Combridge, Narender Singh, Melody Lwo, Eric Smith, Rakesh Gupta, Andy Engin Utkan