Don’t Fear Salesforce’s Workflow Rules and Process Builder Retirement, Embrace It!

Take the Opportunity to Improve Org Stability and Performance

If you’re a Salesforce admin, receiving emails about Workflow Rules retiring may be daunting.

However, this change presents a great opportunity to give your Salesforce organization a significant upgrade, especially for older organizations.

The Evolution of Salesforce Automations

Salesforce Workflow Rules have been around since the Winter ‘04 Release. At that time, they were a game-changer – enabling admins to automate straightforward tasks such as field updates, email alerts, and task creation without the need for code. Workflow Rules have been the preferred tool for over a decade.

As business requirements became more complex, the limitations of Workflow Rules in Salesforce became evident. In 2015, Process Builder was introduced, offering a simpler method for administrators and developers to visually automate workflows and link them into more intricate processes.

For years, Workflow Rules and Process Builders made up the core of declarative automation in the Salesforce world. However, they had limitations in managing complex scenarios.

Enter Flow Builder in 2018 – a powerful new tool that really raised the bar. Suddenly, admins had a flexible and robust way to build out automations visually.

The Tangled Web We Weave

As each new automation tool was introduced, administrators added more layers to their existing Workflow Rules and Process Builders. Before long, numerous Salesforce organizations became entangled in a web of automations triggering in all directions.

We’ve seen this spaghetti automation firsthand at Plative while working with clients. Intricate webs of Workflow Rules, Process Builders, Flows, and custom code all interacting (and conflicting) in unintended ways. 

This often leads to:

  • Recursive loops getting stuck in infinite cycles
  • Bulky, inefficient processes bogging down performance
  • CPU timeouts when too many automations trigger at once

The CPU timeout issue is a real one. It occurs when Salesforce aborts a transaction that didn’t complete within the platform’s time limit, usually due to too much automation executing. For businesses, this can cause major disruptions, lost productivity, and data inconsistencies that negatively impact core processes like reporting, forecasting, and customer communications.

Technically, you can keep using your existing Workflow Rules and Process Builders after their retirement dates – the end of support simply means Salesforce will not investigate or resolve any issues involving those retired automations going forward. However, this is not recommended, as it misses an opportunity to:

  • Improve processing time and avoid CPU timeout limits, both now and as your organization grows in the future
  • Eliminate outdated, redundant, or conflicting automations that no longer align with your current business processes and requirements
  • Consolidate automation logic into a clear, readable, and consistent location using modern tools like Flow Builder

As a rule of thumb, After-Save Flows are estimated to be 50% faster than similar Process Builder automations. Even more significantly, Before-Save Flows can be up to 100x faster than Process Builders in Salesforce. By migrating to Flows, you’ll benefit from blazing fast performance, more advanced functionality, and continued support from Salesforce. 

Source: Record-Triggered Automation | Salesforce Architects

While Apex is always more optimal than any declarative automations from a performance standpoint, trade-offs between maintainability, editability, and performance will always need to be considered based on your org and the capabilities of your team.

At Plative, a top Salesforce consultancy, we’ve seen this automation debt first-hand while helping clients through Workflow Rules retirements. But we also recognize it as an opportunity to really upgrade and optimize the org!

Here’s How to Capitalize on This Transition (And We Can Help! ):

Below are 5 key areas we believe will unlock those Salesforce org Superpowers.

Upgrade Your Automation Strategy

  • Examine all your current automations including Workflow Rules, Process Builders, Flows, and code holistically. Document the requirements, dependencies, and business rules. Then establish clear guidelines and governance on utilizing tools such as Flows versus custom code in the future.
  • Define criteria for when to use which tool based on factors like: complexity of requirements, need for reusability across multiple objects, performance considerations, integration needs, etc. Develop a decision tree or checklist to ensure consistency.
  • Aim for a streamlined, scalable, and maintainable automation approach. Identify any redundant or duplicative automations that can be consolidated. Prioritize automations to migrate based on business impact.

Upgrade Your Processes

Don’t just lift-and-shift legacy automations to Flows. Take this opportunity to revamp core processes from the ground up. For processes like data entry, order management, quote approvals, etc.:

  1. Map out the current state process flow, identifying pain points and bottlenecks
  2. Design the future state optimized process flow, leveraging Flow’s advanced capabilities
  3. Build the new Flows, incorporating screens, loops, conditions, integrations, etc. as needed
  4. Test the new Flow and parallel process changes thoroughly
  5. Train end users on the new streamlined process

Upgrade Your Capabilities

This migration doesn’t just involve admins. Use it as a catalyst for developers to upskill as well. Implement training programs to have them get hands-on experience:

  • Building robust, reusable and scalable automation solutions using Salesforce Apex and Flow
  • Exploring ways to enhance Flows with dynamic UIs using Lightning Web Components
  • Learning best practices around testing, deploying and maintaining Flows/Apex

Consider creating reusable Flow components or templates developers can leverage.

Upgrade Your Code Quality

As you introduce more Flows and Apex code, rigorous testing and code quality practices become paramount.

  1. Implement thorough test coverage requirements and processes (e.g. 80%+ test coverage)
  2. Leverage static code analysis tools to enforce quality and security standards
  3. Automate testing through CI/CD pipelines
  4. Establish processes like peer code reviews to enforce best practices
  5. Set up regression testing to validate existing code isn’t impacted

This transition also presents an opportunity to evaluate your existing Apex codebase. With Salesforce retiring API versions 21.0 to 30.0 by the end of 2025, any legacy code using those older APIs will need updating. Be sure to create a project plan to systematically refactor that legacy code.

Upgrade Your Visibility

As your automation footprint grows, so does the difficulty of monitoring and troubleshooting issues. Implement robust logging and error handling mechanisms:

  1. Build custom logging and error handling into Flows and Apex code using free tools like Nebula Logger and leverage log management/analysis tools to aggregate logs
  2. Set up alerts and monitoring to proactively identify issues
  3. Implement a release management process for deploying changes
  4. Conduct regular log reviews and create documentation

Increased visibility allows you to expedite triage and prevent issues from escalating.

What About The ‘Migrate to Flow’ Tool? Can’t I Just Use That?

Salesforce does provide a “Migrate to Flow” tool to assist in transitioning legacy Workflow Rules and Process Builders over to Flows in Salesforce. However, this tool has some limitations to be aware of.

The Migrate to Flow tool essentially takes a snapshot of the current state of your Workflow Rules and Process Builders and attempts to recreate that same automation logic using Flow. But it does this in a very literal, simplistic way – resulting in Flows that mimic the original automations step-by-step.

While this can save some initial setup time, the migrated Flows won’t take advantage of Flow’s advanced capabilities like screens, loops, conditions, and integrations. They also won’t be optimized for performance or maintainability. You’ll essentially be recreating the same spaghetti of automations, just in Flow instead of legacy tools.

So while Migrate to Flow may provide a shortcut for a bare-bones migration, it shouldn’t be viewed as the end solution. Treat it as an optional first step, with the expectation that the migrated Flows will need to be thoroughly reviewed, redesigned, and rebuilt following best practices.

At Plative, we generally recommend mapping out your ideal future-state processes first, before migrating anything over. That way, you can rebuild automations from the ground up to be streamlined, optimized and aligned with your business requirements – taking full advantage of everything Flow has to offer.

Take the Next Step to an Upgrade Org

Whether you’re a Salesforce admin, developer, consultant or end-user, the Workflow Rules and Process Builder retirement presents a great opportunity to modernize your organization’s architecture and processes. At Plative, we’ve helped numerous clients navigate this transition while optimizing for performance, scalability and long-term maintainability.

Ready to turn this change into a major upgrade for your Salesforce org? Download our Migrate to Flow Planning Checklist and Book an assessment with our team today!


Written by

Luke Thorson

Delivery Manager, Salesforce

Let's Get Started