Welcome to our third and final post in this short series on the Migrate to Flow tool that Salesforce have provided to help Admins migrate their existing declarative automation into Flow ahead fof the upcoming end of life support for Process Builder and Workflow Rules sometime in 2025. In week one, we covered how you can use the tool to migrate Workflow Rules into Flow. Last week we did the same, but for Process Builder. This week, in our final post, I will provide my overall thoughts on the tool, as well as my comments on what I personally feel is the best approach to migrating existing declarative automation into Flow Builder.

Not to provide a spoiler, but I genuinely feel as if the tool leaves a bit to be desired. However, I want to be charitable and fair here. So rather than just listing out the negatives (of which I feel there are quite a few), I will cover both the positives and the negatives. In all honesty, I do feel as if the tool can be used in a good way, but I also can’t lie in this post and say that I would recommend it.

In brief form, how I will handle this post is to break it out down as such:

• My Overall Thoughts on the Migrate to Flow Tool
  • The Good Bits
  • The Bad Bits
• My Views on Using the Tool
  • Should Admins Use It to Begin With?
  • How Could Admins Use the Tool?
  • What is a Better Approach to Migration?

With all that preamble out of the way, let’s move on to go over my thoughts on the Migrate to Flow tool overall.

N.B. Before we dive in, as a quick note, like in last week’s post I may refer to Process Builder as PB and Workflow Rules as WFRs.

My Thoughts on the Tool Overall

We’ll make our start by covering my views on the Migrate to Flow tool overall. We’ll do this by covering what I think the tool does well, and what it does not do well. Unfortunately (another spoiler here), I think there is more points against it than for it. However, I am more than aware that my views on the tool are my views, they may not be yours. So if you disagree with me in my review, do let me know as I would love to hear your thoughts on the tool. You never know, you might convince me and change my mind.

What the Tool Does Well

So first, what does the tool well? To be honest, the thing the tool does actually quite well if you ignore all of it’s shortcomings, are simple 1-to-1 level migrations. If you’re looking for a simple tool to help you migrate your existing declarative in a like-for-like manner with no real additional work to be done on ensuring that your Flows perform to the best possible standard and meet best practice conventions for the most part, this tool will work fine. In my experience of using it, 8/9 times out of 10, your base-level simple PB’s or WFR’s will migrate to Flow absolutely fine with little to no problem. That doesn’t mean there aren’t things to heavily consider before using it, but what I am saying here is that if you have simple PB’s or WFR’s to migrate, this tool will in most cases do the trick just fine. The tool is intelligent enough to determine whether a Flow should be a Before-Save or an After-Save Flow, this is a point in it’s favour for sure. The tool will also automatically create you in-built formulas and variables depending on the PB or WFR being migrated. This also is a point in it’s favour. So while I am not a fan of the tool overall, I can with confidence give it some points in it’s favour because of some of the ways it handles migration of existing automation into Flow from Process Builder or Workflow Rules. Once again, for basic 1-to-1 migrations with little to no additional work, this tool will in most cases do the trick.

As far as the positives go, unfortunately for me that is all I have. If you have anymore, please do comment below and let me know.

What The Tool Does Not Well

Now we get into the negative side of things. My apologies in advance here, but there are quite a few points I want to highlight in this section. So how I’ll approach this, is that I will give a section to each of my main objections with the tool, and explain them.

#1: The Not-So-Great Design Pattern of Migrated Flows

Let’s begin this section by talking about how the Flows themselves are designed through the migration tool. In my opinion the Flows that get created by the tool tend not to follow such a great pattern of design. Granted, I’ve seen Flows that are designed much worse than anything I’ve seen the tool generate (including Flows I’ve designed myself in the past). That being said, I would still honestly say that the Flows created by the migration tool don’t exhibit the best design pattern … I wouldn’t call them bad, I just wouldn’t call them great. By this I mean that in the vast majority of cases I would be designing my Flows very differently to the tool.

An example of this is in the Flow that I created in the WFR migration post. In that post, the migration tool create a Flow with a single update element and created the Flow as an after-save Flow. For that use case, I would’ve normally opted for a before-save Flow, using a decision and an assignment element rather than an update element. A more clearer example of this is with the Process that was migrated in my Process Builder to Flow post. In that post the migration tool created a Flow that included multiple DML Statements in the form of an Update Element, all of these elements were updating the triggering record (e.g. the $Record variable). In the post I opted to again make it a before-save Flow and use Assignment Elements rather than Update Elements. However, the point I wanted to make here is that if I was to keep that Flow as an after-save Flow I would have instead opted to change those Update Elements to Assignments, assigning the relevant values to the $Record variable, and then going to use a singular update element rather than using multiple. This is because in my view, the less DML Statements in a Flow, the better. So in this particular use case, why use two DML Statements where we can achieve the same result and use just the one? Granted, in a Flow that small it isn’t going to matter too much as we can execute up to 150 DML Statements in a Flow, however, what I’m hinting at by this point is applying good habits as a Flow Builder. Here the good habit here is to consolidate DML Statements, opting to use fewer pink nodes where possible by combining DML Statements that carry out pretty much the same task. Basically, less pink and more orange.

#2: The Hodgepodge Naming Convention Patterns

For me personally, the naming convention issue is a real red flag for sure. As I’ve stated extensively in my previous two posts, I have no real stake in what naming convention you choose to use in how you build out your Flows. However, I strongly feel that whatever naming convention you choose to use, you should remain consistent with that as much as possible and stick with it across all of the automation that you build in your org where possible. Does that mean you can’t make tweaks, or decide at a later date that you instead want to pivot to another convention because you now feel that’s a better approach? Not at all! Our views can certainly change the more work we do in a given area. Mine certainly have over the years. Changing views is not really what I’m trying to get at with this point, what I am trying to get at is that we should avoid mixing naming conventions in our individual Flows and across our Flows overall at a general level. Meaning that when one member of your team builds a Flow, they should ideally stick with the agreed upon naming convention as set by your organisation (or in the case of a consultancy, the client). What we shouldn’t be seeing is different naming conventions depending on what member of staff built the Flow in question. That’s my point in this area. Hopefully I’ve been able to make this clear here in this post, as well as in the other posts I’ve written in this blog series.

Now, where the Migrate to Flow tool fails in this area is in two main categories in my view. The first is the inconsistent naming patterns. Depending on the element that has been been migrated, you might have an API name that uses Camel Case, for others you might see Salesforce’s approach to Snake Case. This can be seen on multiple occassions inside of a migrated Flow depending on how many elements are created during the migration process. This in my view is extremely poor design. It more than certainly does not meet best practice standards, which again are to avoid mixing naming conventions within the same piece of automation.

N.B. If you are unsure, Camel Case would look this mainUpdate. Whereas Snake Case would look like this in Salesforce, Main_Update.

#3: The Badly Named Created Elements

Following on from my point on naming conventions, let’s talk about how the Migrate to Flow tool names created elements. I know, I covered this extensively in my previous two posts in this series, but like the previous point, this to me is a massive red flag. So it is worth unpacking this here in a way that can hopefully help guide the conversation. Again, my aim here is to provide some insight on this issue and why I feel it is in fact an issue. This issue, like the previous isn’t one that in most instances can’t simply be fixed, as an Admin can simply rename the elements and resources in the Flow (the only API name that can’t be changed is the one for the Flow itself, but to get around that one can simply save the Flow as a new Flow and change the API name before saving/activating it). So when I raise most of these issues, please do be aware that I’m not saying these are deal breakers for using the tool, just that if you want to ensure your Flows are the best possible version of them after migrating that you’ll need to do a little extra work.

OK, so for this point. The issue really here is how the elements are named after migration. In my opinion as an experienced Flow Builder, I feel that an element should be named something that is short but also conveys what the element is doing so as to make it abundantly clear to anyone who has to use or maintain the Flow what that element is meant to do within the context of the Flow.

Let me unpack what I mean by again highlighting two of the main examples that came up when doing work for this series:

• mainUpdate – Update Element created when migrating a Workflow Rule to Flow.
• myRule_1_A1 – Update Element created when migrating a Process from Process Builder to Flow.

There were more examples of this kind of thing in the Flows that were created during the migrations. But these two examples are actually extremely good examples of the point that I’m trying to make. I can illustrate the issue well by asking a simple question, that being can you tell what these elements are doing based on the name? Well, unless your psychic, the answer to that question will probably be no. If you were to look at an element called mainUpdate, sure you’d be able to say that it’s an update, but other than that could you tell me what it is updating without looking at the element? I highly doubt that you could, I probably couldn’t.

When I say that an element’s label and API name should be clear and concise, what I mean by that is the label ideally should be short enough to be fully visible in the Flow canvas, and both the label and the API name should give a good idea of what the element is doing. For a more fleshed out explanation of the work of the element, that is where the description field comes into play (but I’ll be doing a post on naming concepts in Flow in March around the time of TDX). People who come to work with the Flow after you’re finished with it or have moved on from the project should be able to understand what the element is doing without needing to require a rosetta stone or umpteen hours to read through the documentation that has been prepared on that Flow.

A good example of the naming of an element in my view would be something like this:

• Label: Update Opportunity | API Name: updateOppRecord
• Label: Get Related Contacts | API Name: getRelatedContactRecords

You can see from the above examples that there is slight variance between the label and the API names. This is due to the point I made about trying to make the label short. In my view, if you can set the label name to be somewhere around 25 characters you’re golden. This is because the shorter the label, the more likely it will be to not loose any of it from view in the canvas. The API name in my book can be as long as needed, but it should be clear and to the point. As you will be able to see from above, the elements are named simply clearly enough that you will be able to look at the names and quickly understand what they are doing within the context of that particular Flow. Obviously if you need to include multiple Gets to retrieve related Contact Records, you’re going to want to tweak the names a little bit, but as a general principle this way of naming elements should be beneficial in most use cases.

N.B. I will talk a little more extensively on this topic in a future post in March.

#4: The Inability to Combine Multiple Automations into One Flow

Next on my list is the inability to combine multiple WFRs or PBs into a singular Flow when migrating them across to Flow. This to me is a big barrier to using this tool extensively, as in my experience a sizeable number of WFRs particularly can be merged into a singular Flow. You wouldn’t traditionally have done this with PB, as the recommendation for processes was to create one PB per object (or one PB per object by trigger type). However, for Workflow Rules, many companies would simply just create whatever WFRs they needed for the relevant objects they needed them for. As a result, this means that many companies could have tens of WFRs (or maybe even more than that) against an Object. This in turn means that the possibility of being able to combine multiple WFRs together into singular Flows is highly likely. Now, do we need to do this? Maybe not. After all, for Record-Triggered Flows we can set the Trigger Order of a Flow, and use Flow Trigger Explorer to visualise and update the order in which each Flow fires.

This is where we begin to get into the debate around Flow design patterns and the regular question of, how many Flows should we have per object. Many are still on the one Flow per object train, others (like me) have a slightly different view. In my honest opinion, the best approach right now is to categorise your Flows by business process, having one triggering Flow for each process and then using subflows to handle some of the specific areas of functionality needed in that business process. In practice, this means that you can create Autolaunched Flows that essentially act as templates that can be reused across multiple business processes by passing variables into them from the Flow that triggered the governing Flow that manages that particular business process. Like with my previous points, this concept is something I’ll look to cover during the month of March and tie that to a series on design.

The main point that I am trying to make here, is that I feel that the inability to select multiple pieces of automation and tie them together in a single Flow is a barrier to entry for using the Migrate to Flow tool in my opinion. But once again, it’s just my opinion.

#5: The Big Gaps in What Can and Can’t Be Migrated Across

My final point against the tool, is all of the gaps that the tool has. Basically, in a lot of cases if you’re looking to do anything more than a very basic 1-to-1 migration of one piece of declarative automation into Flow, you’re going to potentially run into barriers. Want to migrate a Workflow Rule that updates related records on another object? Nope, you can’t do that. Want to migrate a Process from PB that includes a Scheduled Action or fires an Approval Process? Nope, you can’t do that either. Basically, if you want to do anything that is somewhat advanced in terms of Flow, then you’re going to at some point encounter a roadblock. In my view, the gaps that the tool offers provides a significant barrier to entry for using the tool. However, if you are aware of what the tool can’t do, that will make it significantly easier to avoid even attempting to migrate those pieces of automation into Flow, and instead you can make a plan on how to rebuild those automations in Flow Builder. Being aware of the tools limitations is a massive need for sure. It will avoid you a lot of pain as you prepare your plan to migrate your older declarative automation into Flow.

Like with all of the other points I’ve made in this post and throughout the series, this isn’t necessarily a deal breaker in terms of using the tool. But in my view it does make using it significantly less appealing to me as a Flow Builder. So while it’s not a deal breaker as such, the big gaps in what can be migrated using the tool makes me lean towards rebuilding rather than migration.

My Views on Using the Migrate to Flow Tool

I have a number of thoughts on how (and if) Admins should use the Migrate to Flow tool. I’ll try and keep my thoughts brief but concise as this post is becoming quite long as it is already. What I’ll do here is briefly share my thoughts under each of the headings listed below. After that I’ll move on to wrap up the post. Like always, I’d love to hear your thoughts in the comments below.

Should Admins Use the Tool?

OK, so for this question. I honestly don’t it’s a yes or no answer … if I’m to be brutually honest I think the answer is it depends. I know, that’s a very Salesforce answer right? That being said, I think it is the totally truthful answer as there are different ways to approach answering this question from both a fair and an honest standpoint. That is why the real answer here is it depends.

For me as an experienced Flow Builder and Salesforce Admin, I would in all honesty not want to use this tool in most cases. There are a number of reasons for this, all of which are really covered in the the things I’ve listed in this post that I don’t like about the tool. But if I was to summarise the reason in a simple and (hopefully) easy to digest manner, it’s really because of the fact that due to all of the ways the tool interferes with my preferred methodology for designing and building Flows, it would take me far longer to use the migration tool and then refactor and update the Flows based on how I design them. For example, the Flow that was built when I migrated the Workflow Rule in my first post over to Flow, I could have built that Flow outright in less than 30 minutes most likely. Whereas the time it would take to migrate the WFR to Flow and to then refactor the Flow according to how I design Flows would most likely exceed 30 minutes … possibly not event including retesting. Now imagine this principle for more complex WFRs or PBs than we covered in this series. Essentially, I would probably be able to produce what I felt was a better Flow in a more timely manner if I built it from the ground up than I would by using the Migrate to Flow tool. So I would honestly prefer not to use it really.

I guess how I would frame it is that for the experienced Flow Builder, it’s probably not necessary for you to use it. It’s probably a tool more suited to Admins with less Flow knowledge. For the more seasoned Flow builder, it’s probably more beneficial to just do your migrations by recreating your existing automation as Flows and deactivating your Workflow Rules and Processes. That’s just my opinion, but as I’ve said, for me I would find it a little more productive to migrate via a rebuild than by using the tool. That being said, like I said a little earlier, if you’re an Admin who’s in a position where you have simple automations to migrate, and you maybe don’t quite have the skills just yet to rebuild your automations as Flows, then the Migrate to Flow will be fine for the most I think.

If So, How Should Admins Use the Tool?

OK, so on to how to use the tool if you’re going to use it. Well, I think to answer that question effectively, I would want to propose a simple strategy with seven key steps. I could probably write a post on this in the future, but for now I’ll just list the steps.

1. Review all your existing Workflow Rules and Processes.
2. Evaluate how each WFR and PB fits within your various business processes.
3. Agree upon a governing model for your Flow based automation (1 per object, many using Flow Trigger Explorer, etc.).
4. Determine which WFRs and PBs can and should be migrated into singular Flows based on the agreed upon model from step 3.
5. Migrate the applicable WFRs and PBs into Flow and carry out any necessary reconfigurations.
6. Test the resulting automations in either debug or in a live form by activating the Flows you created and decativating the WFR/PB.
7. Once testing has been passed, deploy the resulting automation and changes to the WFRs and PBs into your Production org.

N.B. It would be best practice to carry out steps 5 to 7 in a Sandbox environment. Please try to avoid doing this in Production.

N.B. If you would like me to cover the steps I listed above in a follow-up post let me know and I’ll look to that to the post calendar.

What is a Better Approach to Flow Migration?

I’ve sort of covered this a bit in my last point. But the main objective here is to audit your existing Workflow Rules and Processes, to determine what needs migrating and how, then to do the migration and test the resulting automations before finally deploying them. That in a basic form is what I feel is the best approach to Flow migration. While it might sound basic, there is a lot in there. For example, I highlight determining a governance model for automation, that sounds all well and good on paper, but what does that even look like? And who would be responsible for that? The more I write out this post, the more I’m realising that there is a lot more content that needs to be written about some of these topics as I won’t be able to do them justice in this post. Frankly if I was to go into any real depth on some of these points that I’m raising, it would make this post into something that is too long to read.

So I think at this stage what I’m going to do is make a decision to do follow-up posts on some of the topics I’m raising here. Right now I’m thinking particularly around carving out a governance plan for automation and mapping out a migration strategy. I feel those two topics in particular warrant their own posts. However, for the benefit of this post, I need to unpack this point a little bit.

So what is a better approach to Flow migration than simply just diving in and using the Migrate to Flow Tool to migrate all of your existing declarative automations into Flow? After all, my main concern with the usage of this tool is how it can encourage Admins to blindly migrate all of their WFRs and PBs to Flow with little to no consideration of the potential impact it might have on their org.

Here’s what I have in mind for the right approach to Flow migration:

• Audit all of your existing Workflow Rules and Processes.
• Determine which Business Process each WFR and PB fits with.
• Establish a governing model for Flow automation.
• Prioritise which automations need to be migrated and do a staggered approach.
• Migrate the Automation and carry out any necessary changes.
• Test the resulting automation and decativate the original WFRs and PBs.
• Deploy the automations that you are ready to deply, consider doing this in phases.
• Document your newly created automation using Description Fields and other tooling.
• Repeat this overall process until all of the WFRs and PBs you designated for migration have been migrated and tested.

That list isn’t all too different from the list I made of how to use the Migrate to Flow Tool effectively. This is because the principles behind a solid automation migration will apply whether you migrating automation using the tool on a 1-to-1 level, or if you are using a migration through recreation approach. The main difference between this list and the list in my previous point is that you would only be migrating one piece of automation at a time. In the model listed above you could hypothetically be working on the migration of multiple automations, maybe even having multiple team members working on migrations if you’re in an org who has multiple Admins. The approach I have listed above will work well if you have one Admin or multiple Admins. It’s an approach based on strategy … not necessarily the number of Admins you have or the number of existing automations you need to migrate to Flow.

Closing Comments

So that wraps up my thoughts on the Migrate to Flow Tool overall. Again I will apologise if I haven’t sounded all too charitable when speaking about the tool. My aim has been to be as objective as possible, but I find the tool to not be the best solution based on the design model that I feel works best for Flow. I think the tool is fine for basic 1-to-1 migrations of WFRs and PBs, but outside of that my honest opinion is that you’d be far better served by using a migration by recreation approach. I’d honestly love to be wrong here though, I genuinely appreciate the work that the Flow team has put in to make this tool a viable solution for Admins to use in order to migrate their existing WFRs and PBs to Flow. So if you’ve used the tool and have differing thoughts to me on this, please do post a comment and tell me where you think I’m wrong here. Like I say, I’d love to be wrong and to be able to feel as if I can say that the tool is awesome and will meet your migration needs. Right now, I just can’t say that because I feel there’s too many things it doesn’t right or that result in me as a Flow Builder having to spend three or four times longer to change the Flows after migration than it would for just to build the Flows from scratch. But let me know your thoughts in the comments below or on Social Media. I’d really love to hear thoughts from Admins who have used the tool and found it to be a major benefit to their migration projects.

I’d hate to leave this post in a place that sounds negative, so as I wrap up let me once again say that I really appreciate the fact that this tool exists. While it’s not something I would want to use, I do think it is something that a number of Salesforce Admins will find to be a great benefit and time saver in the work they have to with migrating their WFRs and PBs to Flow. I do genuinely think that this tool can help a number of Salesforce Admins, and if you’re reading this post, I hope that it’s benefitting you in the work you do.

As always, if you have any thoughts or comments you’d like to share. Please share them here in this post or via Social Media. I’ll be back later this week with a post sharing the highlights of the Flow Preview from the Spring ’23 round of Release Readiness Live.

Resources

We have three resources to link to this awesome post … all of the resources provided for this post focus on principles around migrating existing declarative automation into Flow. All of these resources offer some really good insight into the principles behind automation migration. When reading though, please do bear in mind that there are many different views on this subject, so some of the points raised may not fall in line with official recommendations from Salesforce (so please do bear that in mind).

How To Analyze, Plan and Prioritize Your Flow Migrations
Wrapping up with the theme of planning how to migrate your existing automation into Flow. Elements.cloud have provided us with this fantastic post on how to analyse, plan and prioritise what automations to migrate to Flow, and how to get them over into Flow Builder. Totally worth a read!!!