Moving to Salesforce Flow: Where Do You Start?

Last year Salesforce made it official that their older automation tools, Workflow Rules and Process Builder, are headed towards retirement now that so much feature enhancement and investment has been made in Flow Builder. For many Salesforce Admins, this announcement might have caused a bit of dread as they think about the many, many “vintage” automations they currently have that will have to be migrated over to Flows. Their experience using Flow Builder might be limited, as well, adding to their apprehension.

If you’re an admin of a Salesforce org that’s been around a while, you could have hundreds of automations to sift through and convert over to Flow, and you will want to be thoughtful in your approach. While Salesforce does provide a native Migrate to Flow wizard in Setup (currently in beta, as of the publishing of this article), you may want to take a more holistic approach than simply converting every existing workflow and process into individual Flows, or you may have automations that don’t meet the criteria to be able to use that tool. 

With so many individual workflow rules and processes to migrate, starting this process could start to look a little scary. Where does one even begin with such a daunting task?

Note: in this blog post, the general term “automations” will be used to refer to anything residing in Workflow Rules, Process Builder, or Flow Builder.

Don’t Panic; Get Organized

Abraham Lincoln once said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe”. If you want to do something well, planning and preparing are key. 

One way to approach this might be to look at the big picture first. Aside from “all automations are now Flows,” what does your desired end state look like, and how will you get there? Making yourself a map of your current state can help you identify where to start. You can utilize an AppExchange package that can provide you a metadata dictionary — there are some well-rated free options to consider — or you might prefer the older school method of copying the text of your automation pages in Setup and pasting them into a spreadsheet you can format to your heart’s content. One tab per automation type, or per object, can help you organize your gameplan. 

This process can be kind of like moving to a new home — you should look at each individual automation you’re considering moving, and ask yourself — “Do I really need to bring this with me?” Now’s the time to tidy up your automation landscape!

Some things to consider as you evaluate your current automations:

• Summary by Objects: Which of your Salesforce objects carry the most technical debt (the highest # of automations)? You might choose to focus on one Salesforce object at a time and rework all of that object’s automations into as few Flows as possible, to help reduce your technical debt. Future You will thank you for the decreased complexity.
• Outdated Processes: Do you have workflows, processes, or existing Flows that aren’t actually doing anything anymore? Maybe they reference an old Opportunity Stage you’ve moved away from, or perhaps they create records for a work process no one is using anymore. 
• Inactive Automations: If you have automations that are inactive, do you really need to keep them around? Don’t be afraid to clean house.
• Consolidate Where You Can: Sort your list by object, entry criteria, or actions. Can you identify ways in which you might consolidate and optimize how these run? Consider utilizing subflows to handle repeatable functionality like field updates, email alerts, task creation, or outbound messages that get called by more than one automation.

• Order of Execution: Consider that in Salesforce’s order of execution, automations will run in a specified order. Was anything built into one specific automation type or another because of where that automation would fall in that order? Maybe not, but it’s worth looking into.

• Evaluate Risk and Complexity: Think about the teams at your organization whose work is impacted by these automations. Do any existing automations send out a customer-facing communication, or are they part of a highly-automated business process? Think about the complexity involved with migrating each specific automation, and identify for yourself where your gaps might be (for more complex automations, you might choose to engage with a partner like Arkus).

Consolidate Where You Can

Once you’ve mapped out what you currently have for automations, you can start sorting and filtering on some of the above criteria. Do you see commonalities that might lend themselves to consolidating some automations into just one Flow, or a “main” Flow that calls some subflows? Map out your ideas; color-code your spreadsheet; make a chart of what “current landscape” and “desired future state” would look like. 

Think about what Future You might like to be able to do when troubleshooting or making updates to these new Flows you will build. It might make sense to work all automations that touch a specific business process into one Flow, or all automations that run when a new Case record is created, for example. You can leverage a Decision Element after that to then parse out what actions need to happen and when - a replacement for the individual entry criteria on those workflows and criteria nodes on processes.

Also consider that email actions can be written directly into Flows, rather than a Flow calling an Email Alert — this can make sense for single-use email notifications that don’t need to be called by any other automations.

Automations, Assemble

Now that you’ve evaluated your current automations and identified opportunities for consolidation, pick a place to begin. You might choose to “start small,” picking a Salesforce object or business process with just a few automations running on it. 

As with any changes you make in Salesforce, make sure to build your proposed Flow(s) in a sandbox environment — and don’t forget to deactivate those existing automations before you begin testing. You’ll want to ensure that your current functionality is maintained, no automations get lost in the move, and that your shiny new Flows behave as you’d expect them to when run by different end users. If you’re looking for guidance on Flow optimization and testing, check out this post on the Arkus blog on that very topic.

Document, Document, Document

It’s always a good idea to document changes made to your Salesforce org. For Flow migration, your documentation might include why you decided to build something a certain way, which users tested the automation, what steps/clicks were part of the testing process, what records you tested with, and what the results were. For each testing attempt, did each intended action fire? Did something not go as planned? Write it down and iterate from there.

This post gave you some places to start, and things to think about, when evaluating the “move to Flow”. What else are you evaluating, or if you’ve done this process already, what did you learn? Let me know on Twitter @txtngmypancreas.