Process Builder Sunset, Part 1: What Salesforce Consultancies Need to Know

This is Part 1 of a two-post series on the Process Builder sunset. In Part 2 we show how Kicksights automates the migration and how you can replicate it manually with the Extraction demo.

Salesforce announced Process Builder's retirement at Dreamforce 2021. It's been years of "you should migrate" messaging, but Summer '25 is different—they're actually turning it off. If you still have active Process Builders after that release, they just stop running. No errors, no warnings at runtime, just silent failures.

The timeline looks like this: Spring '24 started blocking new Process Builders in sandboxes (if you enabled the enforcement setting). Winter '25 disabled new PB creation in production by default—existing ones kept working but showed warning banners. Summer '25 is the hard cutoff. The runtime gets disabled permanently.

You can read more in Salesforce's retirement overview, the Summer '25 release notes, or the architect's guide to Flow.

Why they're doing this

Process Builder was supposed to bridge the gap between simple workflow rules and Apex code. It sort of worked, but it created its own problems.

The performance issues are real. Every Process Builder evaluation spins up a synchronous Apex transaction layer. Flow's orchestrator is actually efficient and doesn't chain evaluations the same way. You can't debug Process Builders properly—there's no instrumentation, no run logs, nothing. Flow gives you debug history, subflow traces, all the stuff you actually need when something breaks at 2am.

ISVs couldn't package Process Builders, which meant they were stuck writing Apex or hoping Flow became viable (it did, eventually). And now that Salesforce is pushing AI everywhere, Flow's typed metadata means Einstein can actually reason about what your automation does. Process Builder metadata might as well be opaque binary blobs for all the tooling can do with it.

What this means for small consultancies

If you're a 5-50 person shop, this is harder than it sounds. Enterprise customers with whole COEs can throw bodies at the problem. You can't.

First, there's the legacy problem. A bunch of your clients are still running Process Builders because "it works fine" and migrations are expensive. When those stop working, you're the one getting the angry call about broken automations. Your SLA doesn't care that Salesforce deprecated it three years ago.

Second, hiring is asymmetric. Finding someone who knows Process Builder well enough to maintain it is easy—it's been around forever. Finding someone who's actually good at Flow and knows enough Apex to handle the complex stuff is much harder. If you haven't upskilled your team already, you're behind.

Third, Process Builders tend to hide governance disasters. You've got cross-object updates everywhere, auto-converted leads that cascade through half the database, stuff that "works" but nobody understands anymore. Those patterns are probably replicated across multiple client orgs, and you won't know until you actually inventory everything.

And finally, this is happening while everyone's trying to sell Einstein, Data Cloud, and whatever else Salesforce is pushing this quarter. Your delivery team is already maxed out.

What you actually need to do

Before migrating anything, you need to know what you have. Every consultancy should be doing this inventory:

1. List every Process Builder and Workflow Rule. Including the inactive ones. Including the ones in managed packages that you didn't write.
2. Map which objects they fire on and what their entry criteria are. You need to know about evaluation order dependencies before they bite you.
3. Document every action: field updates, subflows, invocable Apex, email alerts, Chatter posts.
4. Capture all the branching logic—criteria nodes, scheduled actions, time triggers.
5. Check for integration touchpoints. If your Process Builder calls out to MuleSoft or Workato or some custom API, that's not going to magically work in Flow.

Salesforce's tools are a starting point but they're not enough. Automation Home in Setup shows you PB counts but doesn't give you action details. The Flow Builder migration guide is basically "here's how to do this manually, object by object, good luck." Their automated Migrate to Flow tool handles simple cases and chokes on anything with complex branching or invocable Apex.

What actually breaks

Some failure modes are worse than others.

Time-based actions are brutal. If you have scheduled Process Builder actions (send an email 3 days after opportunity close, update a field a week after case creation), those scheduled jobs just disappear when PB shuts off. The email never sends. The field never updates. You have to extract those time triggers and rebuild them as Flow waits or Platform Events, and you probably need to reschedule stuff that's already queued.

Cross-object updates are tricky because Process Builder let you do some things that Flow won't without Apex. Updating parent records, certain relationship traversals—you'll need subflows or invocable Apex, and you better make sure your recursion handling is right.

Bulk automation is where silent failures get expensive. If someone used Process Builder in a data migration (they shouldn't have, but they did), and it fails silently in Flow, you've got data inconsistency across 50,000 records. Test your Flow replacements with actual bulk loads in a full sandbox before you ship them.

And don't underestimate change management. Process Builder deactivations usually happen during normal change windows, but if you don't communicate clearly, you get production outages. Every retirement should have a CAB entry and a rollback plan, even though rolling back means turning PB back on, which you can't do after Summer '25.

How to talk about this with clients

Don't lead with "we need to pay down technical debt." Lead with "if we don't do this, your revenue operations break in June." Frame it as risk reduction, not cleanup.

Bundle the discovery and migration together. Make it one engagement: inventory, rationalization, Flow buildout. Don't try to sell inventory separately and then come back later for migration—you'll get pushed to the back of the queue.

If the client is interested in AI, Flow is how Einstein automation works. You can use this migration to set up future-state automation instead of just doing a lift-and-shift.

And show them actual progress. Visual diff reports that map Process Builder logic to the Flow replacement help stakeholders see you're not just rewriting the same thing in a different tool. They need to understand that the new version is actually better.

In Part 2 we'll walk through how Kicksights automates the inventory, logic parsing, and Flow generation so your team can deliver migrations in days—plus how to reproduce the process manually using our Extraction demo if you're rolling your own tooling.