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.