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 retirement at Dreamforce 2021. For years the guidance has been "you should migrate," but Summer '25 is the release where execution actually stops. Active Process Builders after that release do not fail loudly. They stop running with no errors or runtime warnings.

The timeline is this: Spring '24 blocked new Process Builders in sandboxes when enforcement was enabled. Winter '25 disabled new Process Builder creation in production by default, while existing processes kept running with warnings. Summer '25 is the hard cutoff. Runtime execution is then 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 designed to bridge simple workflow rules and Apex code. It delivered on that use case, then created new failure modes at scale.

The performance cost is real. Every Process Builder evaluation starts a synchronous Apex transaction. Flow's orchestrator avoids the same chaining pattern. Process Builder has limited operational visibility - there is no instrumentation or reliable run log flow. Flow provides debug history and subflow traces, which helps when problems surface in production.

ISVs could not package Process Builders, so teams either maintained custom Apex or waited for Flow to become viable. With Salesforce increasing AI use, Flow's typed metadata also gives Einstein better context for analyzing automation behavior. Process Builder metadata is harder to model accurately in tooling.

What this means for small consultancies

If you're a 5-50 person shop, this is much harder than it sounds. Enterprise teams can assign larger delivery groups. Smaller consultancies usually cannot.

First, there is the legacy problem. Many clients keep Process Builders in place because migration cost feels immediate and obvious problems are rare. When those automations stop running, your team receives the breakage notifications, not Salesforce. Your SLA is about client uptime, not feature deprecation timing.

Second, hiring is asymmetric. Finding someone who can keep legacy Process Builders running is straightforward. Finding someone who can do Flow and Apex well is much harder. If you have not already invested in upskilling, you are likely behind.

Third, Process Builders can hide governance issues. Cross-object updates appear simple from a UI perspective, and auto-converted leads can create cascades that no one fully understands. Those patterns repeat across client orgs unless they are explicitly inventoried.

This timing matters because teams are also implementing Einstein, Data Cloud, and the next round of Salesforce initiatives. Delivery capacity is already constrained.

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 inactive items and managed-package automations.
2. Map each object trigger and entry criteria, including evaluation order dependencies.
3. Document every action: field updates, subflows, invocable Apex, email alerts, Chatter posts.
4. Capture branching logic, including criteria nodes, scheduled actions, and time-based triggers.
5. Check every integration touchpoint. If a Process Builder calls out to MuleSoft, Workato, or a custom API, confirm the equivalent behavior in Flow.

Salesforce's tooling gets you part of the way there. Automation Home in Setup shows counts, not action details. The Flow Builder migration guide still describes manual, object-level conversion. The automated Migrate to Flow tool handles simple cases, but complex branching and invocable Apex often still need manual handling.

What actually breaks

Some failure modes have higher operational impact than others.

Time-based actions are high-impact. Scheduled Process Builder jobs (email three days after opportunity close, or a field update a week after case creation) are removed when runtime is disabled. The scheduled events do not run. You need to rebuild those paths in Flow waits or Platform Events and often reschedule queued work.

Cross-object updates are tricky because some Process Builder behaviors require subflow or invocable Apex in Flow. Recursive flows are a common risk, so include explicit recursion checks in your design.

Bulk automation is where silent failures become expensive. If Process Builders were used in data migration paths, a Flow replacement can fail without an obvious surface error and leave records out of sync across large volumes. Validate with realistic bulk loads in a full sandbox before production rollout.

Change management still matters. Most Process Builder retirements are scheduled through normal change windows, but unclear communication can still cause production incidents. Treat each deactivation as a change request with a rollback path, and remember that re-enabling Process Builder is not an option after Summer '25.

How to talk about this with clients

Avoid framing this as optional cleanup. Lead with the business outcome: unreconciled automations can affect revenue operations during peak periods. Position the work as risk reduction with clear business impact.

Bundle discovery and migration. Make the engagement sequence explicit: inventory, rationalization, and Flow buildout. Separating those tracks often delays migration and increases handoff risk.

If a client is already evaluating AI-led automation, this migration is a practical path to Future-state automation in Flow, not a lift-and-shift replacement project.

Share measurable progress. Visual diff reports that map Process Builder logic to Flow replacement help stakeholders see that behavior is being preserved where needed and modernized where useful.

In Part 2, we cover Kicksights' automated migration approach and the manual alternative using the Extraction demo for teams that want to build the workflow in-house.