Let's address the elephant in the room ! 🐘
Salesforce kills Workflow Rules and Process Builders, let the migration to Flows begin with a bang! 🔥
Welcome to my first article!
First of all, thank you for subscribing to my newsletter 🫂. Writing this is going to be a new experience for me, and my goal is to share what I know after 10+ years in the tech industry and all the things I continue to learn about Salesforce and Software Development. 🚀
Let's talk about the hot topic on everyone's mind. Salesforce has finally announced that they are officially cutting ties with workflow rules and process builders on December 31, 2025 🎆. We’re happy for them, but now it’s time for us to talk to our therapists about having to face the mess we’ve made over the last 20 years of bad automation 🫠
Wondering how this impacts you? Let’s break it down:
- Forget about PB or Workflow Rules! Stop having to check about 50% of the places where automation could exist, since now all of them will live under 2 tools: One declarative (Flows) and one programmatic (Apex), so devs and admins can stop wanting to kill each other and live in harmony. 🫂
- When it comes to implementing declarative automation, we can now all just focus on learning Flows since they will be the new "one tool to rule them all." 💍
- Certifications ✅ will likely be updated (for example, the App Builder certification), and we'll stop hearing about these prehistoric tools (yep, PB and Workflow Rules are extinct now - like the whole "return to office" movement should be)
What if I’m using tons of workflow and PB today? Don’t I have over a year to migrate?:
I can't count the number of times I've heard this, and the migration work begins one month before the last day the tools are available. I’m not a tarot card reader, but I can tell you this: You'll have Flows that work just as poorly (or worse) than your process builders 😀
Alright Emi, I believe you. Where should I start? 🤔
Now that we're on the same page, let’s talk about the ideal way to start with this:
Let's start by eliminating any Workflow or Process Builder that exists in the ORG and is deactivated. There are two ways to do this, the hard way or the easy way:
If you are a try-hard and want the hard way? Go to the list of Workflow rules or Process Builders and delete them one by one 😅.
You are smart and want to delete all your deactivated Workflows and Process Builders on less than 30 seconds? 🏃
If you use SF Inspector, it's as easy as going to Data Export, pasting the query following query SELECT Id FROM Flow WHERE ManageableState = 'unmanaged' AND Status IN ('Obsolete', 'Draft', 'InvalidDraft'), checking tooling API, run the export, clicking on Delete Records, and clicking on Run Deleted.
Now that we've removed all the deactivated Workflow and Process Builders that weren't being used (because they where deactivated), we can get down to business 🔥
Let's identify what we need to migrate now: 📋
☝️ My first recommendation would be to identify the Workflow Rules and Process Builders by object and make a list of them. It can be a simple spreadsheet with the columns like Object, Metadata Type, Metadata Name, Metadata API Name, Needs To Be Migrated
Once we have the list 📋 organized by objects, we can start the migration of each automation for each object. But wait ✋, did you notice something in the list of columns? We have one called Needs To Be Migrated. This is because if we have automations in Workflows or Process Builders, they are probably from the dinosaur era 🦖.This is a good opportunity to identify if these automations are still necessary.
Take the time to see if the automation still makes sense for the business, and as a bonus, see if the fields used in the automations are still used at the business level.
Let's migrate and get rid of those 🦖 automations:
Once we have our automations that need to be migrated, we can start the migration itself. And here's the best advice I can give you 🫶: don't use SF's Migrate to Flow feature, it's complete garbage 🗑️ and the performance of the auto generated flows will be horrible, not to mention that it doesn't generate entry criteria for our automations, everything runs in an after context (related records), and the names of the elements are assignment1, assignment2, decision1, decision2, etc.
Let's take this opportunity to diagram our automation and migrate it from scratch but effectively. Let's identify if it needs to run in a before (fast field) or after (related records) context, define an appropriate entry criteria for our automation, and use appropriate names for our decisions, assignments, DMLs, etc.
We are almost there, two more steps 2️⃣
As part of each migration, let's write test cases 🪲 for it (because lets’s be honest chances are that you didn’t do it the first time) and do a test run to make sure everything is still working as it is expected 👌.
And now for the fun part, let's deploy 🚀 our new and shiny Flows, deactivate our Process Builders and Workflow Rules, and live a life free of this old automations with the peace of mind that we won't reach December 31, 2025 without having done our migration.
If you've made it this far and you're thinking about deploying using Change Sets 🤮, don't miss the next newsletter where we'll talk about DevOps Center and how to stop deploying changes as if we were in the Stone Age!
As I always say I'll always be grateful to Salesforce ☁️ for releasing new tools and feature and then decide to kill them off a few years later (see you again when we're migrating from profiles to permission sets because profiles can no longer give access to objects and fields) 🚀.
Bonus meme courtesy of SF Ben 🤪
If you liked 👍 this article or find it valuable for others, feel free to share it, and if you have feedback about it, feel free to write to me at hi@whoisemiliano.dev so I can keep improving 🚀
This was crafted with ❤️ by Emi from Montevideo, Uruguay 🇺🇾