Salesforce automation is going to look very different after 2022, particularly with the retiring of Workflow Rules & Process Builder. Which most admins know is on the horizon.

But for the “accidental” Salesforce admins, my unofficial admins, or the non-admins out there who are just trying to get Salesforce off the ground….you may not understand what this means. Or why it’s a big deal!

So let’s dig into what’s going on in the land of Salesforce automation. Because this is one of those technical-seeming tidbits you really ought to know.

What exactly is happening?

For the past few years, Salesforce has been open about their focus on Salesforce Flow. In turn, they’ve moved away from investing time or development on two other legacy automation tools, Process Builder & Workflow Rules.

But they very recently confirmed what many of us saw coming: Workflow Rules and Process Builder will officially retire at the end of 2022. At that point, new automations will have to be built using Flow. Eventually, all existing automations will also need to move to Flow. See the official announcement here for more details.

Now, what does this mean for you! Basically, any existing workflow rules and process builder automations will need to move to Flow.

Skip ahead if you just want to get to the migration options.

Whoa Dee, you’re speaking another language. What are these tools?

Okay! Time for a quick history.

If you’ve ever heard people call Salesforce a powerful CRM, one big reason for that is the automation capabilities. Things like sending automated emails, creating or updating records en masse, building forms, etc..can all be done using Salesforce’s native, declarative automation tools.

Originally, Workflow Rules was THE tool for doing this: simple but powerful. Then in 2015, Salesforce released Process Builder: a more in-depth tool with more functionality, though still not enough to completelyyy replace Workflow Rules.

Sometime in 2017, Cloud Flow Designer (the original Salesforce Flow) came onto the scene. And while this tool had the most functionality, it was also the most complex to learn. As someone who taught herself how to use it in 2019, I can vouch that it was a small nightmare.

So around 2019, Salesforce overhauled the CFD interface and gave us Lightning Flow Builder: same powerful features, but packaged in a much simpler interface. That eventually became what we all (want to) know and love as Salesforce Flow.

p.s. If you’re familiar with Process Builder and feeling anxious about Flow, here’s a video I put together that compares the two side-by-side.

What’s so great about Salesforce Flow?

Short answer is the robust functionality. Unlike the other automation tools, Flow is the closest one can get to coding on the Salesforce platform, without actually coding on the Salesforce platform.

If that last sentence didn’t mean anything to you…that’s okay. 😌 Just know that when it comes to building highly functional, highly custom solutions, Salesforce programming (also known as Apex) has historically been the only way to do that. With Flow, us non-coding admins have another option.

In fact, Flow is one of many declarative tools that allow Salesforce admins to do big things without needing programmatic/coding knowledge. If you’d like to learn more, here’s some info on that distinction.

p.s. This isn’t to say that Salesforce Flow can totally replace code. It can’t! But it lets admins do far more with our Salesforce orgs for less, since dev expertise costs.

How do I know if my org uses these automation tools?

You almost certainly do. I’m like, 99% certain.

If your org uses a managed package like NPSP, or any other integrations, then you definitely have automations that are part of that installation. You’re also likely to have automations if you used a consultant to set up your instance, OR if you’re using any of the standard Salesforce cloud products (like Sales Cloud).

But check it out for yourself! Automations can be found in Salesforce setup. Log into Salesforce > Open Setup (instructions here if you’re not sure) > Search for any of these in the Quick Find box:

• Workflow Rules
• Process Builder
• Flow

From there, you can peek behind the curtain by opening any active automations. See how they’re built (Process Builder is probably the most intuitive) so that you can get a sense of what the heck everyone’s talking about.

But wait! Most of my org’s automations are part of a package (like NPSP). Do I have to migrate these myself?

Presumably, managed package vendors will eventually meet Salesforce’s migration requirements. Otherwise, I don’t see how customers could install/upgrade packages after the retirement date!

But let’s not assume. Reach out to your package vendors – especially those not housed under Salesforce, Inc – and see what their plans are/ if they recommend customers migrate themselves in the meantime. (To my knowledge, NPSP has not made any announcements yet.)

And remember that even IF your vendor plans to migrate those automations, you’ll still have to upgrade that package in your Salesforce org. If you’ve never done this before, check out the Installed Packages section of the Salesforce Help Site. Here’s a specific article on Upgrading Packages

Hmm. This feels like a lot.

If you feel this way, you’re not alone!  Many customers weren’t thrilled to learn that Workflow Rules and Process Builder – tools that are the backbone of (thousands?) of Salesforce orgs, some many years old – are now facing obsoletion.

Add to this the reality that for admins to properly leverage Salesforce, they must now spend time learning a tool that is arguably far more complicated than its predecessors. AND for those that wear the Salesforce hat unofficially, you’re probably reading this at your org & thinking:

But I can see this from Salesforce’s side, too. Why invest in 3 declarative automation tools when they can invest in making 1 great? Flow pretty much does what the others can, and more efficiently.

It’s like the Salesforce team is cleaning up some of its own technical debt (or maybe product debt is a more accurate term). So while there’s some pain now, let’s hope those investments make Flow continually better and increasingly easier to pick up.

How can I start learning to Flow? Luckily, you’ve got a few options!

• Take a paid course on a website like Udemy or PluralSight. The Salesforce Flowsome blog has a few recommendations if you need, but I recommend previewing any instructors that stand out to you on those e-course sites

• Start getting hands on with Trailhead, Salesforce’s gamified e-learning platform. Here’s one trail with multiple Flow modules, but you may be able to find more by searching the Trailhead site

• If you prefer to bootstrap your learning for free, get on Youtube. This is how I first learned Flow. You’ll find some full on courses (the more recent, the better), but you can use it to look up specific Flow concepts as you go

And with that…I will also plug my growing Youtube Playlist on Flow Basics ^_^

Okay! What are my options to migrate? 

The ideal scenario is to audit your existing automations before migrating them manually. That way, you only migrate the ones you need AND you can even consolidate where feasible.

Not to mention, manually migrating gives you an excuse to practice building in Flow. And you can only get better with practice.

But if that approach is unrealistic – because of time or otherwise – you do have other options:

• Salesforce has already built a tool for migrating Workflow Rules over to Flow. Another for migrating Process Builder automations is pending. See this detailed guide by Salesforce Ben on how to use the Workflow migration tool

• You can also look into 3rd party migration tools. ConvertToFlow is one option provided by UnofficialSF. This is also mentioned in the Salesforce Ben article ^^

• If you work with a Salesforce consultant, see if you can add this to their plate. This impending retirement is already common knowledge in the ecosystem, so they should be able to help. (At the very least, confirm that any new automations they’re working on are ONLY built in Flow)

• If you don’t have a consultant, you may be able to find a Salesforce pro who’s happy to have this task outsourced to them for a flat rate. Check out any of the online communities where Salesforce Admins lurk. I have a few listed here.

• If you have zero budget, consider organizing this into a volunteer opportunity. You always want to proceed carefully when letting volunteers into your Salesforce org. But unlike implementations – which are big and multi-faceted – I think Flows are a great, sufficiently isolated volunteer project! Plus, your volunteers will benefit from hands-on automation experience

If you’re considering a volunteer – make sure they’re familiar with how to create, test & deploy in/from sandboxes. Also, see here for more general tech volunteer tips.

For those curious about what will happen if you don’t migrate those automations in time….hard to say 🤷🏻‍♀️. If the enforcement is anything like MFA, maybe they’ll automatically migrate any remaining automations to Flow on the very last day that the features are still “alive” (probably past 2023). OR, maybe those remaining automations will be lost forever!

Best we can do is keep an eye out for an update from Salesforce, as they release more of their retirement timeline.

And that’s a wrap. What’s on your mind when it comes to Flows?

Thanks for reading! What’s your org’s plan? Do you have questions or reactions? New information that I missed? If so, please let us know in the comments.