Salesforce Process Builder is on its way out — build new automation in Salesforce Flow instead. Process Builder was the point-and-click tool that extended Workflow Rules: you picked an object, set criteria, and ran immediate or scheduled actions such as field updates, create record, email alert, and Apex calls. Salesforce has since blocked the creation of new processes in modern orgs and is steering every org toward record-triggered Flow through the built-in Migrate to Flow tool. Existing processes still run for now, but Process Builder is end-of-life direction, so any new work should start in Flow.
Key takeaways
- Don't build new Process Builder processes. Salesforce has stopped allowing new processes in newer orgs; Flow is the supported path forward.
- Process Builder = object + criteria + actions. It extended Workflow Rules with create-record, call-Apex, and multi-criteria logic on one canvas.
- Flow does everything Process Builder did, and more — before-save updates (fast, no extra DML), decisions, loops, scheduled paths, and screen flows.
- Use the Migrate to Flow tool (Setup → Process Automation → Migrate to Flow) to convert existing processes, then test in a sandbox before activating.
- Consolidate per object. Keep as few record-triggered flows per object as practical so the order of execution stays predictable.
- Hedge the dates. Salesforce has signalled retirement, but exact end-of-support timing has shifted across releases — confirm in current release notes before planning a hard cutover.
What was Process Builder and how did it work?
Process Builder lived under Setup → Process Automation → Process Builder (older orgs nested it under Workflow & Approvals). A process was bound to one object and fired when a record changes, a platform event occurs, or another process invokes it.
Each process was a stack of criteria nodes evaluated top to bottom. For every node you chose how it decided:
- Conditions are met — field / operator / value rows combined with AND, OR, or custom logic.
- Formula evaluates to true — a single Boolean formula.
- No criteria — just execute the actions.
When a node matched, its action group ran. Process Builder could do more than Workflow Rules:
- Create and update records, including related records.
- Send an email alert.
- Submit a record for approval.
- Post to Chatter.
- Launch a Flow.
- Call an Apex method.
- Invoke another process.
You could also schedule actions for a future time — the rough equivalent of Workflow time-dependent actions. If you still maintain time-based reminders this way, see our Flow-based reminder guide for the modern pattern.
Workflow Rules vs Process Builder vs Flow: which should you use?
| Capability | Workflow Rules | Process Builder | Salesforce Flow |
|---|---|---|---|
| Status (2026) | Retired for new rules | Retired for new processes | Recommended / actively developed |
| Build new automation? | No | No | Yes |
| Same-record field update | Yes | Yes | Yes (fast before-save, no extra DML) |
| Create / update related records | Limited | Yes | Yes |
| Email alerts | Yes | Yes | Yes |
| Decisions, loops, variables | No | Limited | Yes |
| Scheduled / delayed actions | Time-dependent | Scheduled actions | Scheduled paths |
| Call Apex | No | Yes | Yes (invocable) |
| User interaction (screens) | No | No | Yes (screen flows) |
| Performance | Good | Heaviest | Best (before-save bypasses extra DML) |
| Recommendation | Migrate to Flow | Migrate to Flow | Build here |
The takeaway is consistent: Flow is the one tool Salesforce wants you to standardise on. It absorbs the simple field updates of Workflow Rules — see our Workflow field update guide for that classic action — and the richer logic of Process Builder, while running faster and being easier to debug.
How do you convert Process Builder to a record-triggered Flow?
Take a typical process: on Opportunity, when Stage = Closed Won and Amount is above a threshold, tick a High_Value__c checkbox and create a follow-up task.
In Process Builder that was one criteria node ("Stage equals Closed Won AND Amount greater than ...") with two immediate actions. In Flow you split the work by when it should run:
- Before-save, record-triggered flow for the same-record field update. It runs before the record is committed, so setting
High_Value__cneeds no extra DML and is the fastest option. - After-save, record-triggered flow for anything touching other records — here, creating the Task — because related records need the saved record's Id.
The pieces map cleanly:
| Process Builder | Record-triggered Flow |
|---|---|
| Object + "when a record changes" | Flow start: object + Created / Updated |
| Criteria node | Decision element |
| Immediate field update (same record) | Before-save assignment |
| Create record / email / Apex | After-save Create Records / Action |
| Scheduled action | Scheduled Path |
You rarely hand-build the first draft. Open Setup → Process Automation → Migrate to Flow, select the process, and let Salesforce generate an equivalent flow that you then review, refine, and test in a sandbox before activating. When you tighten the generated flow, its entry conditions translate the old criteria into a formula such as:
ISPICKVAL({!$Record.StageName}, "Closed Won")
&& ISCHANGED({!$Record.StageName})
&& {!$Record.Amount} > 50000What should you watch for when migrating to Flow?
- One tool per object, ideally. Mixing active Workflow Rules, Process Builder, and Flow on the same object makes the order of execution hard to reason about — consolidate into record-triggered flows.
- Split before-save vs after-save. Put same-record field updates in a before-save flow; put everything else (related records, emails, Apex, scheduled paths) in after-save.
- Bulkify and test. Flows run in bulk like Apex triggers, so test with many records, not one, and stay inside the governor limits.
- Migrate in a sandbox first. Run the Migrate to Flow tool, validate the new flow, deactivate the old process, then deploy.
- Document and follow conventions. Consistent naming and fault paths keep the org maintainable — see our Salesforce customization best practices.
If you have a backlog of legacy processes and Workflow Rules to retire, our Salesforce consulting team can audit your automation and migrate it to Flow with regression testing.
Frequently Asked Questions
Is Process Builder being retired?
Yes. Salesforce is retiring Process Builder along with Workflow Rules and has stopped allowing the creation of new processes in modern orgs. Existing processes still run, but all new automation should be built in Salesforce Flow. The exact end-of-support date has shifted across releases, so confirm the current timeline in Salesforce's release notes before planning a hard cutover.
Can I still create a new Process Builder process?
In most newer orgs, no. Salesforce blocks the creation of new processes and directs you to Flow. You can usually still edit or deactivate existing processes, but the supported path for anything new is a record-triggered flow.
What is the difference between Process Builder and Flow?
Flow is a superset. Process Builder ran criteria and actions on a single object after save. Flow adds before-save updates (faster, with no extra DML), decisions, loops, variables, scheduled paths, screen interactions, and easier debugging — covering everything Process Builder did and more.
How do I migrate Process Builder to Flow?
Use the Migrate to Flow tool under Setup → Process Automation → Migrate to Flow. Select a process, let Salesforce generate an equivalent record-triggered flow, then review, refine, and test it in a sandbox. Deactivate the original process only after the new flow is validated.
Should field updates go in before-save or after-save flows?
Put same-record field updates in a before-save record-triggered flow. They run before the record is committed, so no additional DML statement is needed, which makes them the fastest option. Use after-save flows for related records, emails, Apex, and scheduled paths.
Does Flow replace both Workflow Rules and Process Builder?
Yes. Salesforce's direction is to consolidate Workflow Rules and Process Builder into Flow. Flow handles the simple field updates that Workflow Rules did and the richer multi-action logic of Process Builder, so you can standardise automation on one tool.