The End of the Salesforce Workflow Rules Era

So after reading that Salesforce was now sunsetting the technology that had allowed me to escape doing Oracle ERP implementations AND financed my bike racing habit, I felt, as the kids say, a little shook. If you’re responsible for a Salesforce org that’s been live for more than five years, I’m sure you can relate—though less from nostalgia and more because you know you have to go through the process of migrating from Workflow Rules to Flows.

While you may feel stressed, there’s no reason to worry. Realistically, this shift represents a great opportunity for you, your company, and your Salesforce org, so long as you take advantage of the runway Salesforce is giving you for the change.

Below I’ll outline a few steps you can take to engage with your business stakeholders, confirm their needs, review your build, and redeploy business logic via flows. (Of course, you can skip those steps and go straight to happy stakeholders and more free time to future-proof your career by learning about AI by taking a look at Sweep. We can help.)

Step 1: Assess your Workflow Rules in Salesforce

Before you start ringing the alarm bells, figure out what your exposure to Workflow Rules looks like. If you’re comfortable with admin tasks, dive in and look through the list of active Rules. If you have no idea what those words mean, reach out to your IT team or your Salesforce Services partner or use a tool like Sweep to support your analysis.

It’s also important to note: Salesforce Workflows won’t get turned off altogether, they just won’t be supported. So you could be okay, but the only way to know how much risk you run is to get a good grasp of what is actually built.

Step 2: Confirm the existing Salesforce process

As Winston Churchill said, never waste a crisis. There is a better than average chance that this does not match perfectly with what you have built in Salesforce. And that is OK! Business processes “drift” over time. It happens for a bunch of valid reasons, but the main point is, the fact that Salesforce is making this change is a great, guilt-free excuse to reach out to your business stakeholders and confirm how they are working.

“I know, I know, process review meetings are time consuming. Yeah, it really is a bummer Salesforce is doing this to us. Yeah, I hear you… So next Thursday at 2PM? Great!”

Confirming the process will let you make sure you understand what should be happening in the eyes of the business, instead of relying on what is built, which may be working as designed but not as expected.

Step 3: Find opportunities to improve how you work in Salesforce

I spent more than a decade helping companies try to do what they do better with Salesforce. In all those years the three words that best predicted cataclysmic failure: “lift and shift.”

Different tools have different strengths and weaknesses. When you migrate from one tool to another you have to take this into account. Flows can do a lot of things that workflow rules simply can’t do, so after you’ve confirmed the process your business wants to follow, give them back a draft with some suggestions to change it based on new things you can automate. It might end up being a little more work and taking a little longer, but if you design for the toolset from the beginning your end result will not only be better on day 1, it will be better suited to scale over time.

It’s also worth noting that you don’t have to go to Flows. If you have a strong development team (or work with a partner), and you are confident in your business process, Apex is still a totally viable option in Salesforce. Just know, once you go this route, you will always need access to a developer to maintain it.

Step 4: Take your time and over communicate

Because Workflow Rules have been around for a while, there’s a chance you’ll be touching processes and procedures that have been largely the same for some time. This will rattle people.

Get your changes built out in Flow (or Apex) as quickly as you can. Gather a group of your end users, explain to them what has changed, and give them the opportunity to experiment and provide feedback. For extra credit, you might also give them a crash course on the capabilities of flow, so they can brainstorm a little based on areas they would see value in their day to day (as an added bonus, prepping these types of materials is one of the best ways to make sure you understand how flows work).

Once you’re all agreed on a v1, make sure you communicate out to people that the changes are coming, when the changes are in place, and then follow up to see how they are doing. Opening these communication channels can both keep people calm and give you great insight into how to add more value after the big change is done.

Step 5: Build with iteration in mind

In my experience, the most flexible Salesforce solutions are the most successful. Flows are an incredible tool and you can do a lot of things with them. But you don’t need to do all those things on the first release. Focus on maintaining business continuity and plan on evolving the process and the automations that support it over time.

The retirement of Workflow Rules in Salesforce marks the end of an era. If you use this as an opportunity to engage with business stakeholders, find areas for improvement, and keep communication open, you’ll set yourself up for success in the next chapter of the ecosystem. Using a process visualization and management tool like Sweep can shorten development time, and lead to better collaboration, and a more accurate end-state. If you’d like to learn more about it, please book a meeting today.