Salesforce to Retire Workflow Rules and Process Builder

Share this article...

Rumors have been swirling for quite some time about the potential for Workflow Rules and Process Builder retirement – and it’s true, it really is happening. 

Salesforce has been rapidly enhancing Flow’s functionality and encouraging us to move away from using Workflow Rules and Process Builder. If you’ve been keeping a close eye on the support documentation on Salesforce Help or Trailhead, you may also have noticed that the advice on which automation tool to use has been updated to the following message:

“For all behind-the-scenes automation needs, we recommend that you use Flow Builder.” Trailhead: Choose the Right Automation Tool

In this article, we’ll examine the current retirement timeline. Plus, we’ll provide you with some ideas and resources to get started.

Workflow Rules and Process Builder Retirement Timeline

During Dreamforce ‘21, Patrick Stokes (the Product Manager responsible for the retirement ) explained there would be a formal end-of-life roadmap, governed by an end-of-life council.

As of Winter ’23, you can no longer create Workflow Rules, however, you can still activate, deactivate, and edit any existing Workflow Rules. From Summer ’23, you will no longer be able to create Process Builder Processes either! You should now build all new automation using Flow Builder and start planning to move existing automaitons to Flow.

Why are Salesforce Retiring Workflow Rules and Process Builder?

Much of the value in a CRM tool lies in automating manual tasks. By automating repetitive, time consuming tasks, we can free up time to perform activities that generate new sales and improve customer retention. This is where the money is – and this is the true ROI (return on investment) that Salesforce can provide.

Salesforce have always understood the importance of automation and provided multiple tools over the years. Each tool seemed to be a better version of the last, giving us new ways to create ever more complex process automation, using clicks not code.

READ MORE: The History & Future of Salesforce Automation

Salesforce have ended up supporting several automation tools with overlapping capabilities – the main three being Workflow Rules, Process Builder, and Flow.

There are several problems with having multiple tools:

  • It’s difficult to get an overall picture of your automations and your automation health when they are spread across several products.
  • Businesses’ automation requirements are becoming ever more complicated, requiring more sophisticated tools.
  • It’s costly and time consuming to maintain and enhance multiple tools – therefore, it makes sense to work on developing just one of the three tools. Salesforce can now focus on enhancing and future-proofing Flow.

Why Flow?

Flow is capable of so much more than either Workflow Rules or Process Builder, and the majority of parity gaps have been addressed.

In particular, Flow offers:

  • Better overall performance.
  • Functionality to improve high-volume automation such as Fast Field Updates (Before Save).
  • Powerful error handling and debugging.
  • Repeatable and reusable functionality such as the use of Sub-Flows.
  • Additional features such as Screen Flows.

That only scratches the surface of what Flow has to offer…

What Next?

Whilst there’s no need to panic about the Workflow Rule and Process Builder retirement, there is certainly a level of momentum required at this point. Depending on the age and complexity of your org, you could have hundreds if not thousands of automations.

Let’s be very clear here – the migration tool from Salesforce are a great resource, but they are not the answer to all your migration needs. The current Salesforce migration tool is a 1-1; this means that 100 Workflow Rules would create 100 Flows. This is a problem…as using the tool could create hundreds of Flows!

As part of your migration project, a ‘rebuild and enhance’ strategy is advised – you should map out all existing automations and work out how they can be combined in to an optimal Flow strategy.

So where should you start?

1. Learn How to Use Flow

For many, there will be a learning curve when it comes to using Flow. You’ll definitely want to complete the Salesforce Flow module on Trailhead. Next, Salesforce Ben has plenty of resources to help you on your way! Here are just a few suggestions, but there are many more on our website:

2. Get Comfortable with Flow Jargon

I think half the battle to becoming proficient at using Flow is understanding the terminology. We’ve put together a complete A-Z of all the Flow terms you need to know – from Variables to Loops, we’ve got you covered.

READ MORE: A-Z Guide to the Salesforce Flow Builder

3. Determine Your Flow Strategy

Avoid creating an unruly mass of flows by following best practices and creating a Flow strategy. Read out complete guide below…

READ MORE: How Many Flows Should You Have Per Object?

4. Explore the Flow Trigger Explorer

Want an easy way to visualize your existing flows on an object? Look no further – the Flow Trigger Explorer will show you a birds-eye view of all flows for a specific object in a particular situation, e.g. upon record create.

READ MORE: Introducing Flow Trigger Explorer: View All Your Triggered Automation in One Place

5. Start Thinking Like a Programmatic Developer

Flows are subject to specific limits such as SOQL query limits and DML statements. You might hear that you need to “bulkify” your Flows. Sound a bit complicated? Never fear, Tim covers these concepts in his Ultimate Salesforce Flow Foundation Course.

Find out more about Flow limits and how to avoid them:

READ MORE: Complete Guide to Salesforce Flow Limits and How to Avoid Them

6. Pay Special Attention to Testing and Debugging

“With great power comes great responsibility”… this is so true of Salesforce Flow! As you’re getting to grips with this amazing automation tool, you’ll need to get comfortable with governor limits, testing, and unexpected errors.

READ MORE: How to Solve Salesforce Flow Errors

7. Try Out the Flow Migration Tool

We’ve put together a complete guide with a video to show you how to use the migration tool!

READ MORE: Migrate Salesforce Workflow Rules & Process Builder to Flow

8. Build All New Automation in Flow

Now that you’re practically a Flow Pro, build any new automation request in Flow! We all know that hands-on experience is the best way to become proficient with a Salesforce feature.

9. When an Existing Automation Needs Changing, Rebuild in Flow

Yes, it’s tempting to keep updating automations in Workflow or Process Builder while you can! However, it’s not in your best interest in the long term… Do you future self a favor, and when you get a requirement to update an existing automation, rebuild it in Flow.


Workflow Rules and Process Builder have been around for quite some time (Workflow especially) so migrating your existing processes to Flow will be no easy task. Not only will setting up new flows take time, there is also the need to upskill for many Salesforce professionals, who may not yet be entirely comfortable with using Flow. 

That’s why it is so important to start planning your Flow migration and get hands-on with Flow – starting now. As usual, we’re incredibly fortunate in the Salesforce ecosystem that we have an abundance of resources, both from Salesforce and the community. Let us know what you think about the Workflow Rule and Process Builder retirement in the comments.

43 thoughts on “Salesforce to Retire Workflow Rules and Process Builder

  1. I knew it was being pushed but wasn’t expecting this considering how user-friendly the process builder was. I hope the conversion tool they refer to is robust. we have very complex builder running for extremely important parts of our business.

  2. I was expecting this. When you navigate to a field which is being used in a process builder and press the “Where is this used?” and click on the reference label URL next to Type = Flow, it will automatically convert to a flow which you’ll be able to save.

    1. Actually, it does not convert to flow, rather Process Builder is internally a simple type of flow under the hood. There is a conversion tool available now at that will convert both WorkFlows and Process Builder.

    2. Yes – as Daryl says, it doesn’t actually convert it; you can’t save the edits to automations created in Process Builder when you open them in Flow because they’re missing some of the metadata. (There may be some you can, but not the ones I’ve explored)

  3. Worried about Outbound Soap Messages. Flows / Process Builder doesn’t current handle that capability. Is there a plan to offer “the same” functionality in Flow?

  4. Makes sense this was coming. Reducing the options for automation tools and increasing the ability of Flow makes sense to me. Though I feel for those that have built years of automation into WF Rules and Process Builder

  5. From this article, sounds like existing workflows will still work (at least beyond Winter 2023). So is there a need to migrate existing automation? Would it be enough to learn how to use Flow so new automations are created in this way?

    1. Hi Karl,

      All dates are currently Safe Harbor and existing Workflow Rules and PB won’t disappear for some time yet. I suppose the rollout of conversion tools and prevention of new rules will be just over a year, but who knows when they will remove existing ones from the platform?!

  6. As things currently stand, Field Updates made within an Approval Process can’t trigger a Flow. So Process Builder needs to stick around until that is fixed.

  7. It’s interesting what will happen with SF Certifications. As of the October’20 till May’21 the Workflow Rules were among the “preferred” ways to deal with business process automation in SF Certification Questions (Admin, Developer, etc…)

    1. I’m studying for the admin exam right now so I’m really concerned about this. I guess I am going to have to contact SF support. I don’t think the current exam has been updated to reflect this.

  8. Flow is a great tool, but when you have something simple like a field update or an email alert, a workflow rule is so much easier and faster to implement. And for process-heavy objects like Cases, I’m worried that we’ll end up with a Flow that’s a snarling mess of nodes that will be a nightmare to maintain.

  9. I will need to re-think my strategy around when to add on to an existing automation component (Process) vs when to create a new automation component (Flow or Process). Any thought around which criteria should define a distinct Flow?

  10. And nobody yet is concerned about the fact that flow is STILL in BETA? We’ve implemented a complex flow in my org, and the thing is buggy as all get out. And as my TA would point out, just like Processes, not fully bulkified.

    You can take my processes, (and maybe I’m just showing my age here), but Salesforce can pry Workflow out of my cold, dead hands…

    1. Christine Marshall



      Thanks for your comment – what makes you think Flow is still in Beta? Flow Orchestrator is Beta but Flow/Flow Builder is not – at least I can’t find any information to say it is?


    2. Christine Marshall


      Hi again!

      I’ve spoken to my contacts at Salesforce who confirm that Flow is not Beta – it was GA in the Spring ’19 release.

      Hope that helps!

  11. Does anybody know if Flow Triggers will have access to CURRENT formula field values during the BEFORE PHASE (like the soon-to-be retired Workflow Rules has access during the BEFORE PHASE)?

    Because right now they don’t — Flow Triggers can only access PRIOR record values!

    Problem Scenario:

    (A) We have several cross-object formula fields that evaluate 10+ different objects to derive a complex status for reporting.
    (B) This complex status needs to be indexed for reporting — meaning we must use a primitive text field marked as “External Id”.
    (C) Significant integration / automation (3rd Party Vendor Programs) makes recursion a problem so AFTER SAVE is best avoided.

    Today, we use Workflow Rules to just transfer the value of the formula into the indexed text field.

    This doesn’t work with Flow Triggers. To the best of my knowledge, soon-to-be-retired Workflow Rules is the ONLY THING IN SALESFORCE that can perform this function! Not even a custom-coded solution can perform this task.

    Can anybody tell me if I am missing something?

  12. Any idea why Salesforce is depreciating process builder?
    PB is the preferred automation tool for 95% of functional Salesforce people, as flows are more complex to do.

    1. Christine Marshall


      Salesforce feel it’s important to unify process automation, moving away from multiple tools which hampers maintenance and innovation, choosing instead to focus on a single tool – Flow. There are also known limitations and performance issues with PB, so Flow is the better option.

  13. Adrienne D. Millican


    What will happen to approval processes? Should those be done through flow as well now? It seems to me that there are aspects of approval processes (like using some of the merge fields in templates) that have never worked quite right. And approval processes run on workflow rules essentially, right?

    1. Christine Marshall



      There are no plans to retire Approval Processes at the moment, so they should continue to be used! You’re right though, they do work on Workflow Rules essentially…

    1. Christine Marshall


      Hi Rameez,

      According to Salesforce you will no longer be able to create new Process Builders from 2023, however existing Process Builders will still work. These date are Safe Harbor and all subject to change.


    1. Confirmed your concern is valid Craig.

      I landed on this site after the SF MC Connect app automated process to setup workflow rules (enabling the connection to MC) failed to setup.

      Below is the email I received when the SF automatic setup process ran.


      The following actions failed and should be performed manually to complete your marketing cloud configuration. Please refer to for instructions.

      Email Send Backup Workflow : IO Exception: Read timed out
      Email Send Scheduled Send Workflow : IO Exception: Read timed out
      Mobile Send Backup Workflow : IO Exception: Read timed out
      Mobile Send Scheduled Send Workflow : IO Exception: Read timed out
      Triggered Send Backup Workflow : IO Exception: Read timed out

  14. Salesforce is moving way too fast with the retirement deadline of the WorkFlow and Process Builder. Those tools, if I understand correctly, will effectively be shut down for future edits or the creation of new automations with only about a year’s notice. That is entirely unrealistic. Yes, Flows have been around for several years, but organizations should have been giving a longer deadline for planning purposes – say two fiscal years.

    The time required to learn and master Flows – a much more complex tool, based on coding concepts – is much greater than prior automation tools. Non-IT admins such as those at small-to-medium nonprofits or businesses simply can’t be expected to pick it up in a few weekends, a month or two, or after working a few Trailheads while juggling other duties as might have been done with Process Builder. Flows are a different beast that require greater understanding, more intensive training, more trial and error, and great care to implement.

    Then there is the time required to rebuild, test, and deploy old automations as new Flows. That’s assuming an organization has the bandwidith internally to develop internal expertise. If it doesn’t have internal resources, then it will need the budget to hire outside help to migrate its automations to Flow and perhaps manage them long-term, much like organizations did in the “olden days” when organizations had to hire programmers to automate systems.

    This is potentially a step backwards for some organizations who will lose Admin-Friendly automation tools that made Salesforce popular in its early days. And Salesforce is giving them a 1-year deadline to to make the change, all while proclaiming #LetItFlow from the mountaintops as if things are hunky dory and this isn’t going to cause real hardship for smaller customers.

    Maybe, just maybe Salesforce should provide a two year window for retirement, stop adding complexity to Flows for that two years, and focus on improving: a) Flow ease of configuration, b) implement more user-friendly language, c) offer free Flow classroom training courses for nonprofits, c) implement improved error messaging – that doesn’t require extra configuration to get meaningful error messages, and anything else that makes Flows more Admin-friendly.

  15. Since Quick Actions are the only task that is not handled by Flow (It’s currently handled by Process Builder) , will SF incorporate this feature into flow any time soon? . (I have not heard anything about that.) Thanks.

    1. Christine Marshall


      Hi Tony,

      You can launch a Flow using a Quick Action. Not sure what use case you have when you say Quick Actions are not handled by Flow?

  16. i came accross two functionalities which were working in process builder and stopped working when I pmoved to flow:-
    1. check for profile of current user with doesn’t work in flow, so replaced it with in flow
    2. checking of null doesn’t seem to work in flow, we have $flow.blank, but it doesnt check if the value is null..

    Need such improvements in flow before we move out Process builder completely


  17. Hello All – i have heard that come Winter 23 you wont be able to edit FB or workflow anymore – but i heard this verbally. Has anyone seen this in any salesforce documentation at all please? I know they will remove the ability to create new – but ive not seen the edit documents but its important for me to know. ( Edit especially in PB is effectively a new anyway, as you have to clone it , which creates new, and then you activate the clone). So i can see how edit wont be possible, but id rather have it in official documentation and im not sure about workflow – can anyone help?

  18. Is there a tool/app that will show me all of our process builders, WF rules and flows, the objectst they operate on, etc? I am currently creating a spreadsheet to map out all of our PB, WF rules and flows so we know what is what and know what we have to amalgamate, and it is so time consuming!

  19. Vanraj Rajubhai Odedara


    what are the risks and considerations that need to be taken BEFORE the migration needs to happen. If risks are identified, what can be done to mitigate these?

  20. For people wondering about the SFMC connector:
    There is nothing customers need to do at the moment:
    – Workflow: the first time the user clicks ‘Marketing Cloud’ tab in Sales Cloud, if the workflows are still active, they would become inactive after the 242 version of the package is deployed. As part of this ( article, we suggest checking for old workflows not being deactivated automatically. 

    – Journey Builder Process – once we cutover and deprecate Process Builder, anytime a journey is published or stopped, the Process Builder would become inactive and replaced with a Flow. However, the Process Builder retirement from Journey Builder Salesforce Data Event has not been enabled everywhere so most customers are still using Process Builder for JB purposes at this point.

  21. Hello there, We are planning to migrate from workflows to flows, and struct with a problem. We have email alerts attached to current workflow hence there are a lot of pending emails in the Time-Based Workflow queue. What happens to them when I deactivate and move to new flow? Is there a way to re-parent them under this new flow? If we left the email on scheduled actions queue, they will get deleted whenever an update happens to the related record.

Add Comment