Process Builder
Process Builder is a Salesforce declarative automation tool, released in 2015, that lets administrators define multi-step business processes through a visual canvas.
Definition
Process Builder is a Salesforce declarative automation tool, released in 2015, that lets administrators define multi-step business processes through a visual canvas. It runs on record save events, evaluates a sequence of criteria nodes, and executes immediate or scheduled actions when criteria match. Process Builder replaced most workflow rule use cases and introduced cross-object updates, scheduled actions, and process chaining that workflow rules could not handle cleanly.
Salesforce announced in 2021 that Process Builder would be retired alongside workflow rules, and the Setup UI removed the New button for processes in 2023. Existing processes continue to run and remain editable, but no net-new processes can be created through the standard UI. Like workflow rules, processes still live in tens of thousands of production orgs and are being migrated to Flow as part of automation modernization. The migration is rarely urgent but always on the long-term roadmap.
How Process Builder shaped a generation of Salesforce automation
The visual canvas and node model
Process Builder organized automation as a sequence of criteria nodes, evaluated top to bottom on every record save. Each node had a criteria block ("When does this branch fire?") and an action block ("What does it do?"). The visual layout made it easier to read than workflow rules, especially for processes with several conditional branches. Most administrators learned Process Builder by recreating their workflow rules visually and adding the few branches that workflow could not express.
Immediate versus scheduled actions
Each criteria node could fire immediate actions, scheduled actions, or both. Scheduled actions queued for the future, similar to time-dependent workflow but with more flexible scheduling (any number of days or hours after a specified date field). The queue sat at Setup > Paused and Waiting Flow Interviews, visible to admins for inspection and manual deletion. Scheduled actions caused most of the production incidents Process Builder is remembered for, because criteria changes mid-flight produced records in inconsistent states.
Cross-object updates and the "Update Records" action
Process Builder introduced cross-object updates that workflow could not perform cleanly: a process on Opportunity could update fields on the related Account in the same transaction. This was a major improvement but also a major source of complexity, because the update fired downstream triggers on the related object, which often triggered yet more processes. Recursion limits and order-of-execution surprises were the daily-life cost of this flexibility, and most legacy Process Builder content carries the scars.
The deprecation timeline and current state
Salesforce announced Process Builder retirement in 2021, alongside workflow rules. The Setup UI removed the New button for processes starting roughly with Winter '23. Existing processes continue to run and remain editable. Salesforce has not announced a final removal date, and the official guidance is to migrate to Flow over time without urgency. Net-new automation should always go in Flow now. Maintenance of existing processes is acceptable, with migration prioritized when a process needs significant changes or when it sits on a high-volume object.
Performance and order-of-execution behavior
Process Builder runs as part of the save order, similar to workflow rules but with subtle differences: each process runs as its own Flow interview under the hood, which means it counts toward Flow CPU and DML limits. On high-volume objects with multiple processes, the cumulative cost can blow governor limits during bulk DML. The "Update Records" action also re-fires the save order on related objects, which can cascade. This is why migration to a consolidated record-triggered flow per object usually performs better than the original Process Builder content.
Process versus Flow at the technical layer
Process Builder was always Flow under the hood. Each process compiled into a Flow definition that the runtime executed. The visual UI was different, but the runtime was the same. This is why Flow can absorb every Process Builder use case: the underlying engine is identical. The difference is in author-time UX, governor-limit handling, and the ability to handle bulk DML cleanly. Flow's bulkification was always better; the Process Builder UX hid it from view but did not change the underlying behavior.
Migration patterns and the converter tool
Salesforce ships a Migrate to Flow tool that handles many simple Process Builder conversions. It runs at Setup > Migrate to Flow, picks a target process, and produces a record-triggered flow approximating the original logic. Complex processes (multi-node, scheduled actions, cross-object updates) often need manual rework. The recommended pattern is one consolidated record-triggered flow per object, replacing several Process Builder processes with branching logic inside a single flow. This usually performs better and reads more clearly than the original.
How to maintain (and migrate) Process Builder processes
You can no longer create new processes through the standard Setup UI. The realistic activities are auditing existing processes, editing them carefully when business needs change, and migrating them to Flow. Net-new automation should always be built in Flow.
- Audit the existing processes
Setup > Process Builder shows every process across the org. Export the list with a metadata retrieve (Flow.processBuilders) to a spreadsheet. Note which objects have multiple processes (consolidation targets), which have scheduled actions (high migration risk), and which have cross-object updates (recursion risk).
- Edit an existing process
Setup > Process Builder > select the process > clone it and pause activation on the original until the change is tested. Modify the criteria or actions, validate in sandbox, then activate the new version and deactivate the old. Process Builder does not allow editing an active process directly.
- Plan the migration to Flow
Group processes by object. Plan one consolidated record-triggered flow per object that absorbs all the related Process Builder content. Note scheduled actions and cross-object updates because these often need manual handling. Set a deactivation date for each process being migrated.
- Use the Migrate to Flow tool for simple cases
Setup > Migrate to Flow runs the converter on a selected process. Review the generated flow carefully: scheduled actions translate to Scheduled Paths, but the timing semantics differ. Cross-object updates often need manual flow tweaks. Treat the output as a starting point.
- Rebuild complex processes manually in Flow
For processes the converter cannot handle, build the record-triggered flow by hand. Use Decision elements for branching, Assignment elements for field writes, Subflows for shared logic across objects, and Scheduled Paths for time-delayed actions.
- Deactivate the migrated process
Once the Flow version is validated, deactivate the Process Builder version. Keep it deactivated rather than deleted so you can re-activate if regression appears. Document the migration date and the corresponding Flow API name for traceability.
- Monitor for missed scheduled actions
After deactivation, watch Setup > Paused and Waiting Flow Interviews for any actions that were queued before the migration. These still fire from the old process. Decide whether to let them complete or delete them manually to avoid double-execution with the new flow.
The Salesforce object the process applies to. Cannot be changed once the process is created.
The filter that determines whether a node fires. Supports field comparisons, formulas, and AND/OR logic.
When the process fires: on create only, on create and edit, or only on records that meet criteria changes.
- You cannot create new processes through the standard Setup UI as of Winter '23. Net-new automation must be built in Flow. Existing processes can still be edited.
- Each Process Builder process runs as its own Flow interview under the hood. Multiple processes on the same object can compound CPU and DML governor cost during bulk loads.
- Scheduled actions sit in the Paused Flow queue until they fire. Changing process criteria after queueing can leave actions scheduled that no longer match the current logic.
- Cross-object updates from a process re-trigger the save order on the related object, potentially firing more processes. Recursion limits catch the worst cases, but performance still suffers.
- The Migrate to Flow converter handles simple cases. Complex processes with scheduled actions, cross-object updates, or multi-node criteria almost always need manual rework after conversion.
Trust & references
This term has been renamed to Flow.
View current pageCross-checked against the following references.
- Process Builder OverviewSalesforce Help
- Workflow Rule and Process Builder RetirementSalesforce Help
- Migrate to Flow ToolSalesforce Help
Straight from the source - Salesforce's reference material on Process Builder.
- Process Builder OverviewSalesforce Help
- Process Builder vs. FlowSalesforce Help
- Order of ExecutionSalesforce Developer
Hands-on resources to go deeper on Process Builder.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Is Process Builder still supported?
Q2. What replaces Process Builder?
Q3. What should you do with existing Process Builders?
Discussion
Loading discussion…