by Chris Taylor 
In the summer of 2020, Salesforce announced that Flow was the future and started putting more resources behind the development of the tool. While they also stopped the future development of other tools. Then, a year later, Salesforce announced its plans to retire Workflow Rules and Process Builder starting in Winter’22 (October 2022).
But what does this mean for your current automation?
Well, no need to panic. Salesforce is not planning to turn everything off in a single day, leaving you high and dry. This will be a phased approach. They know many customers have many Workflow Rules and Process builders supporting critical business processes.
However, now is the time to start planning for the future.
Creating a Flow migration plan
When looking at migrating to Flow, you should not only consider converting your current automation into Flows. You should also be taking this as an opportunity to review your entire automation strategy. Many of your automation processes will have likely built up over the years. Additionally, many are created without documentation and requested or created by people who no longer work at your organisation. This means it is not a job you can tackle alone.
We recommend the following four-step processes:
1 – Document your current automation
Look at everything you have in Workflow Rules, Process Builder, Flow and Apex. Document what is triggering these processes and the action they are taking. You will often find processes that no longer do anything. For example, they are triggered by an Opportunity stage that no longer exists. Or you will find processes that you were not aware of, such as sending an email alert to a mailbox that is no longer monitored.
It is essential to understand the automation that is running, no matter which way it is built. This ensures you have a complete understanding of the impact on the platform when building automation. It also ensures you are not duplicating processes.
At Nebula, we approach this by focusing on this process one object at a time. We start with the most critical objects first. It involves visually drawing out current automation and drawing lines between relationships. This helps identify bottlenecks and specific areas with a heavy amount of automation.
2 – Reviewing process with the business
Once you have everything documented, work with business stakeholders to understand what the system should be doing. These stakeholders should not be limited to management. They should contain a mix of user groups, including end-users who tend to spend most of their day on the platform. This will ensure the processes cover all users and do not rely on presumptions.
The simplest way to achieve this is to gather groups of people in a room (physical or virtual) and complete a journey map workshop (they are not only for customers). Once this process is complete, you may notice that requirements do not align with what the platform is doing.
You will likely find that the system is automating processes that the business is unaware of. Or you may also find legacy processes that are no longer required. Take this opportunity to remove any processes you can. Then take time to streamline as many processes as possible to ensure the system does what the business needs.
3 – Design your business processes
With Workflow Rules and Process Builder out of the question for future development, you are left with Flow or Apex. While deciding which bits of automation are required, you will get a feeling of the complexities of these processes.
Salesforce is planning to introduce tools to support automation migration from legacy tools. However, this should not be your first choice.
Although Apex may not sound admin friendly as it is code, the one thing to remember is that Flow is also code. It just has an interface on top to build it. Often, Apex is simpler to write, maintain and configure when written well. Apex has many benefits over Flow, including the ability to write tests. Tests provide a warning system for when your Apex is going to fail. Often, changes are made to other parts of the system that causes your Flow/Apex to fail. Tests help you identify this before it goes wrong. Currently, this is something Flow cannot do.
4 – Start building
Once you have chosen your tool, it is time to build your new processes (in a Sandbox, of course). While building, it is important to have documentation and a consistent naming convention. Also, make sure to use description boxes so that anybody looking at your automation in the future understands what is going on.
Once you have technically tested that your new processes work, it is then the turn of the end-users to test. There are many benefits of User Acceptance Testing (UAT), including the system being used in a way that you are not familiar with. At the end of the day, these are the people who will be using the system daily.
Once everything is signed off, it is time to release your changes into production. It is important to deactivate and remove the old automation to ensure both are not triggered when deploying to production.
Not sure where to start?
Although we have broken it down into a four-step process, this can be a daunting and time-consuming task. At Nebula, we have worked with many clients to improve and support their automation strategy. As the deadline approaches, now is the perfect time to get in touch with one of the team to help support you through this journey.