Salesforce Process Builder is being retired — Salesforce has officially sunset it in favour of Flow Builder, and all Process Builder automations must be migrated to Flows. If you’re asking “Process Builder vs Flow” in 2026, the answer is clear: build everything new in Flow, and plan to migrate your existing Process Builder automations. This guide explains why Flow is the unambiguous successor, covers the different Flow types and when to use each, explains before-save vs after-save triggers (a critical efficiency distinction), and provides practical guidance for migrating from Process Builder to Flow.
The best comparison is the one that makes the automation choice easier to support.
A useful explanation should help the reader decide which path suits the current setup.
That means the guide should focus on practical consequences instead of feature labels.
For many teams, the real question is which tool fits the long-term automation plan better.
It should also show where one option feels simpler and where the other gives more control.
A good comparison should explain how each tool works in everyday admin use.
That makes the topic important for admins and teams that care about maintainable automation.
Salesforce Process Builder vs Flow is a useful comparison because both tools automate business logic, but they do it in different ways and with different levels of flexibility. Teams often compare them when they need to decide how to build or modernise automation in the platform.
Why Process Builder Is Being Retired
Process Builder was Salesforce’s visual automation tool from 2015–2021. It served its purpose but had architectural limitations that made it increasingly difficult to maintain at scale:
- Process Builder could only branch in a simple if-then structure — complex branching required multiple separate Processes chained together
- No loop capability — iterating over a list of related records required Apex code
- Could not query data from other objects during execution
- Multiple Process Builders triggering on the same object created difficult-to-debug interaction patterns
- Performance issues — Process Builder always runs after-save, consuming DML operations for every action, even simple field updates
Salesforce Flow’s architecture addresses all of these limitations. Starting in 2023, Salesforce has been running migration programmes encouraging customers to move from Process Builder to Flow, and Process Builder is no longer receiving new feature development. Salesforce’s official guidance: do not build new automations in Process Builder; migrate existing ones to Flow.
Salesforce Flow: The Unified Automation Platform
Salesforce Flow is a visual, point-and-click automation builder that handles the full range of automation complexity — from simple field updates to multi-step processes with loops, data queries, external HTTP callouts, and user interaction screens. Flow Builder (the visual designer) uses a canvas with element types that are dragged and connected:
- Record element (Get Records): query Salesforce data using SOQL-like filter criteria and return matching records for use in subsequent elements
- Record element (Create Records): create one or more new records
- Record element (Update Records): update one or more records
- Record element (Delete Records): delete records matching criteria
- Decision: branch the flow based on condition logic — equivalent to an if-else statement. Multiple outcomes with complex condition groups (AND/OR logic)
- Assignment: set variable values for use in later elements
- Loop: iterate over a collection of records, executing elements for each record in the list
- Screen: display an interactive user interface — input fields, dropdowns, radio buttons, data tables — for user-facing flows
- Action (Core Action): call Salesforce built-in actions — send email, post Chatter, submit for approval, send custom notifications
- Action (Apex Action): call invocable Apex methods — enabling complex logic or external HTTP callouts from a Flow without writing a complete Apex trigger
- Subflow: call another Flow from within a Flow — enables reusable automation components
Flow Types: Which to Use When
Record-Triggered Flow
The direct replacement for Process Builder. Runs automatically when a Salesforce record is created, updated, or deleted — no user action required. Record-Triggered Flows are the most commonly used Flow type for CRM automation.
Configured with: trigger object (e.g., Opportunity), trigger event (Created, Updated, Created or Updated, Deleted), and entry conditions (e.g., only run when StageName changes to ‘Closed Won’).
Record-Triggered Flows run in two modes (chosen at Flow configuration):
- Before the record is saved: the Flow runs and can set field values on the triggering record before it is written to the database. No DML operation is consumed for field updates — the record is simply modified in memory before the save commits. Fast and efficient. Best for: defaulting field values on creation, validating field combinations before save, calculating formula-like values that require logic not achievable with formula fields.
- After the record is saved: the Flow runs after the record is committed to the database. Can query related records, create/update/delete other records, send emails, post Chatter, and call actions. Best for: creating related records when a condition is met (create a Task when Opportunity reaches Proposal stage), sending notifications, updating related records based on the triggering record’s change.
Best practice: use before-save Flows for any action that only modifies the triggering record’s own fields. Use after-save Flows when you need to interact with other records or perform actions outside the triggering record. A before-save Flow that sets a field value does not consume a DML operation — it is significantly more efficient than an after-save Flow that updates the same record via an Update Records element.
Screen Flow
Interactive Flows with user-facing screens — prompts, forms, guided processes. Screen Flows are launched by a user (from a Button, Quick Action, Lightning component, or Experience Cloud page) and present a series of screens to collect input, display data, and perform actions based on user responses.
Use cases for Screen Flows:
- A guided account planning wizard — a button on the Account record opens a Screen Flow that walks a rep through entering a complete account plan (decision criteria, competitors, key contacts, next steps) with validation at each step
- A quote creation wizard — launches from an Opportunity and guides the rep through building a product configuration, selecting pricing, and generating a quote without navigating to multiple separate record pages
- A customer onboarding checklist — a Customer Success Manager launches a Screen Flow that creates all the standard onboarding tasks, sets the account health field, and sends a welcome email in a single guided process
Scheduled Flow
Runs automatically on a defined schedule — once, daily, or weekly — processing a batch of records matching specified criteria. Scheduled Flows replace the legacy Workflow Rule scheduled actions.
Use cases:
- Daily: check all Leads created more than 30 days ago that are still in “New” status and create a task for the rep to re-evaluate or recycle to marketing
- Weekly: calculate the pipeline coverage ratio for each Sales Manager and post a Chatter notification with the number to their profile
- Monthly: find all Contacts at customer Accounts where the Account has had no Case or Opportunity activity in 12 months and flag the Account for CSM review
Autolaunched Flow
A Flow with no user interface and no automatic trigger — it must be launched explicitly by another process: another Flow (via Subflow element), an Apex class (via Flow.Interview), a REST API call, or a named Apex invocable action. Use Autolaunched Flows to build reusable automation logic that multiple triggering contexts can call — effectively, a callable automation function.
Platform Event-Triggered Flow
Triggers when a Platform Event message is published — used in event-driven integration architectures where external systems publish events to Salesforce and Flows respond to them. As external systems mature toward event-driven patterns, Platform Event Flows become the preferred integration trigger over polling-based integration approaches.
Migrating Process Builder to Flow
Salesforce provides a Flow Migration Tool (Setup → Automation → Flows → Migrate to Flow) that converts some Process Builder automations to equivalent Flows automatically. The tool handles straightforward automations but requires manual review for complex Process Builder logic.
Migration steps:
- Audit your existing Process Builder automations: Setup → Automation → Process Automation. Note which trigger objects each Process Builder uses and which actions it performs.
- Run the automated migration tool for simple Processes — review the generated Flow for accuracy before activating
- For complex Processes (multiple chained processes, Apex callouts, complex branching), build the replacement Flow manually in Flow Builder — this is an opportunity to consolidate multiple Process Builders into a single, well-structured Record-Triggered Flow
- Test the Flow in a Sandbox with representative data before deactivating the Process Builder in production
- Deactivate the Process Builder after confirming the Flow handles all test cases correctly
A key migration opportunity: if you have three separate Process Builders triggering on the same object (a common pattern that grew organically), consolidate them into a single Record-Triggered Flow with Decision elements handling what each separate Process Builder handled. This improves performance and debuggability significantly.
Flow vs Apex: When to Use Each
Flow handles the majority of automation use cases without code. Use Apex when:
- The logic requires complex data structures or algorithms not available in Flow elements (sorting, complex string manipulation, mathematical operations beyond what Flow’s formula functions support)
- The operation involves high-volume bulk processing where Flow’s performance at scale is a concern
- External HTTP callouts with complex request/response handling are required — Flows can call Apex actions for external callouts, combining Flow’s simplicity with Apex’s HTTP handling capability
- Transaction control is required — Apex allows savepoints and rollbacks; Flows commit all actions unless an error occurs
A practical architecture: build the high-level automation logic in a Record-Triggered Flow, and delegate specific complex actions (data transformation, external API calls) to invocable Apex actions called from within the Flow. This keeps the automation logic visible and maintainable in the visual Flow Builder while using Apex only where its capabilities are specifically needed.
The best automation choice is the one that fits the team’s long-term process. If the trade-off is unclear, the system can become harder to maintain.
Conclusion
The Process Builder vs Flow question has a clear answer in 2026: Flow is Salesforce’s automation platform, Process Builder is being retired, and every new automation should be built in Flow Builder. The investment in learning Flow — understanding before-save vs after-save triggers, Record-Triggered vs Scheduled vs Screen Flow types, and the Loop and Decision elements — pays immediate dividends in more capable, more maintainable automation than Process Builder could deliver. Organisations with large Process Builder libraries should prioritise migration: each Process Builder automation deactivated and replaced with a Flow simplifies the automation landscape, improves performance, and reduces the risk of unexpected Process-to-Process interaction bugs.
Sources
Salesforce, Flow Builder Documentation (2026)
Salesforce, Process Builder Retirement Announcement and Migration Guide (2025)
Salesforce, Record-Triggered Flows: Before-Save and After-Save (2026)
Salesforce Trailhead, Automate Your Business Processes with Flow (2026)
Salesforce Release Notes, Flow Enhancements (2026)