Salesforce Process Builder retirement date end of support is a topic every Salesforce admin must understand before their automations break. The salesforce process builder retirement date end of support has been phased in gradually, giving organizations time to prepare.
Salesforce officially announced that Process Builder and Workflow Rules will no longer be available for creating new automations after December 31, 2022, with full end-of-support for existing processes arriving in 2023 and beyond. The problem is that many organizations still run critical business logic on Process Builder, and migrating to Flow can feel overwhelming.
This guide covers the exact timeline, what it means for your org, and five practical steps to migrate safely without disrupting your operations.
Understanding the Salesforce Process Builder Retirement Timeline
The retirement of Process Builder did not happen overnight. Salesforce rolled it out in phases to give admins time to adapt, and the salesforce process builder retirement date end of support is now a key milestone in every admin's planning calendar.
The first major milestone was Summer '21, when Salesforce announced that Workflow Rules and Process Builder would eventually be retired in favor of Flow. By Spring '22, admins could no longer create new Workflow Rules. The critical date for Process Builder was December 31, 2022 — after this, creating new Process Builder processes was blocked in all orgs.
Understanding the salesforce process builder retirement date end of support timeline helps you prioritize which automations to migrate first.
According to Salesforce's official documentation, existing Process Builder processes continue to run in maintenance mode, but Salesforce strongly recommends migrating to Flow. The Salesforce Help Center states that "Flow is the future of automation on the Salesforce Platform."
How to apply this: Check your org's current automation inventory by running the Salesforce Optimizer report or navigating to Setup > Process Automation > Process Builder to see how many active processes you still have.
Why Salesforce Is Retiring Process Builder
Salesforce is consolidating its automation tools into a single, more powerful platform: Flow. Process Builder and Workflow Rules served admins well for years, but they had limitations. The salesforce process builder retirement date end of support reflects this strategic shift toward unified automation.
Flow offers everything Process Builder does plus advanced features like screen flows, scheduled paths, and better error handling.
Salesforce's official position, as stated in their automation documentation, is that "Flow Builder provides a single, unified automation solution that scales with your business needs." Admins who embrace the salesforce process builder retirement date end of support as an opportunity rather than a burden often discover that Flow solves problems Process Builder could never address.
The retirement also simplifies governance. Instead of managing automations across three tools (Workflow Rules, Process Builder, and Flow), admins can consolidate everything into one. The salesforce process builder retirement date end of support ultimately reduces technical debt and improves org performance.
How to apply this: Audit your existing automations and categorize them by complexity. Simple record updates can move to Flow quickly, while complex multi-step processes need more planning.
Step 1: Inventory Every Process Builder Process
You cannot migrate what you do not know exists. Start by creating a complete inventory of all active Process Builder processes in your org, keeping the salesforce process builder retirement date end of support firmly in mind as your deadline driver.
Use the Salesforce Optimizer or run a SOQL query against the FlowDefinitionView object to list every active process. Document the following for each: process name, object it runs on, trigger criteria, immediate actions, scheduled actions, and any invocable processes it calls.
With the salesforce process builder retirement date end of support already passed for new processes, every active process in your inventory represents migration work that must be completed.
A common scenario: an org with 10 years of accumulated automations often discovers 50+ active processes, many of which overlap or conflict with each other. This inventory phase also reveals redundant automations you can consolidate. Since the salesforce process builder retirement date end of support prevents editing existing processes, you must identify issues now rather than later.
How to apply this: Export your process list to a spreadsheet using Salesforce Data Loader or a reporting tool, then tag each process as "simple," "complex," or "candidate for deletion."
Step 2: Map Process Builder Logic to Flow Equivalents
Every Process Builder action has a direct Flow counterpart. Understanding this mapping speeds up migration significantly, especially given the salesforce process builder retirement date end of support constraints on editing legacy processes.
The table below shows the most common mappings:
| Process Builder Feature | Flow Equivalent | Action to Take |
|---|---|---|
| Immediate Actions | Auto-launched Flow elements | Recreate as Flow elements |
| Scheduled Actions | Scheduled Paths | Use Flow's scheduled paths |
| Invocable Process | Subflow or Apex action | Call a subflow from Flow |
| Criteria Nodes | Decision element | Rebuild logic in Flow |
| Record Updates | Update Records element | Map fields directly |
Salesforce provides a built-in migration tool called Migrate to Flow that automatically converts many Process Builder processes into equivalent flows. However, not all processes convert cleanly — complex ones with multiple criteria nodes often need manual rebuilding.
The salesforce process builder retirement date end of support means you cannot simply edit the original process to fix conversion issues; you must resolve everything in Flow.
How to apply this: Run the Migrate to Flow tool on one simple process first. Review the generated flow, test it in a sandbox, and learn the patterns before tackling complex processes.
Step 3: Rebuild and Test in a Sandbox First
Never migrate directly in production. Sandbox testing is non-negotiable for a safe transition, particularly because the salesforce process builder retirement date end of support leaves no room for post-migration edits to legacy processes.
Create a full or partial copy sandbox, then use the Migrate to Flow tool or manually rebuild your processes as flows. Test every scenario: record creation, record updates, scheduled actions firing on time, and error handling. The salesforce process builder retirement date end of support means any issues you miss during testing cannot be fixed by reverting to Process Builder.
One real-world example: a healthcare organization migrated 30 processes to Flow and discovered during sandbox testing that two scheduled actions were firing twice because the original Process Builder had overlapping criteria. Catching this in production would have caused duplicate patient notifications.
With the salesforce process builder retirement date end of support already in effect, their only option would have been to fix the Flow in production — a much riskier proposition.
How to apply this: Set up a test plan with specific record scenarios for each migrated flow. Use Salesforce Sandbox environments to validate before deployment.
Step 4: Deploy Migrated Flows in Phases
Roll out your migrated flows incrementally rather than all at once. This reduces risk and makes troubleshooting easier, especially since the salesforce process builder retirement date end of support means you are working with a one-way migration path.
Start with low-risk, low-volume processes. Deactivate the Process Builder version and activate the Flow version. Monitor both for a week before moving to the next batch. The salesforce process builder retirement date end of support timeline may have already passed, but that does not mean you should rush your deployment.
Salesforce's recommended approach, according to their Trailhead module on automation migration, is to "deactivate legacy automations only after confirming the new Flow performs identically in production." This phased approach prevents business disruption. Every batch you complete moves you further past the salesforce process builder retirement date end of support and closer to a fully modernized automation architecture.
How to apply this: Create a deployment schedule that groups processes by object or business function. Deploy one group per week, monitor error logs, and only proceed when stable.
Step 5: Deactivate Legacy Processes and Document Everything
The final step is deactivation and documentation. Leaving old Process Builder processes active alongside new flows causes duplicate actions and data inconsistencies. After the salesforce process builder retirement date end of support, deactivation is the only action you can still take on legacy processes.
Deactivate each migrated Process Builder process after confirming the Flow works correctly. Keep the deactivated process in your org for reference — Salesforce does not require deletion. The salesforce process builder retirement date end of support does not mean you must delete anything; deactivated processes serve as useful documentation of your migration history.
Document your new Flow architecture thoroughly. Include flow names, descriptions, trigger objects, and any dependencies. This documentation helps future admins understand your automation landscape. Since the salesforce process builder retirement date end of support prevents future edits to legacy processes, your Flow documentation becomes the single source of truth for your automation logic.
How to apply this: After deactivation, run a final audit using the Salesforce Optimizer to confirm no active Process Builder processes remain. Update your team's internal documentation with the new Flow names and logic.
Frequently Asked Questions About salesforce process builder retirement date end of support
What happens to existing Process Builder processes after the retirement date?
Existing Process Builder processes continue to run after December 31, 2022, in maintenance mode. Salesforce has not announced a hard cutoff date for existing processes. However, they will not receive new features, and Salesforce's official guidance is to migrate proactively.
Some orgs run legacy processes for years, but this creates technical debt and increases risk if Salesforce eventually enforces a hard deadline. The salesforce process builder retirement date end of support should be treated as a warning to migrate now rather than wait for a forced cutoff.
Can I still edit Process Builder processes after the retirement date?
No. After December 31, 2022, you cannot create new Process Builder processes or edit existing ones. You can only view, deactivate, or delete them. If you need to change automation logic, you must rebuild it in Flow.
This is why migrating before you need to make changes is critical — waiting until a business requirement forces your hand leads to rushed migrations. The salesforce process builder retirement date end of support means every future automation change must happen in Flow.
Does the Process Builder retirement affect Workflow Rules too?
Yes. Workflow Rules were retired alongside Process Builder. Salesforce stopped allowing new Workflow Rule creation in Spring '22, and existing rules are in maintenance mode. If you still have active Workflow Rules, they should also be migrated to Flow. The Migrate to Flow tool handles both Process Builder and Workflow Rule conversions.
The salesforce process builder retirement date end of support applies to the entire legacy automation suite, not just Process Builder in isolation.
What if my Process Builder process calls an invocable Apex class?
Invocable Apex classes work identically in Flow. When you migrate a process that calls an invocable Apex method, the Flow version can call the same Apex class without modification. This is one of the easiest migration scenarios. Simply recreate the process logic in Flow, add an Apex Action element, and reference the same invocable method.
The salesforce process builder retirement date end of support does not affect your Apex code — only the Process Builder layer that calls it.
How long does a typical Process Builder to Flow migration take?
Migration time varies widely based on complexity. A simple process with one or two immediate actions may convert in under an hour using the Migrate to Flow tool. Complex processes with multiple criteria nodes, scheduled actions, and invocable processes can take several days of testing and refinement. Organizations with 50+ processes typically plan for a multi-week migration project.
The salesforce process builder retirement date end of support means you should start this planning as soon as possible, even if you have already missed the deadline for new process creation.
Key Takeaways and Next Steps
- The salesforce process builder retirement date end of support means no new Process Builder processes after December 31, 2022, with existing ones in maintenance mode
- Migrate to Flow using Salesforce's built-in tool, but test thoroughly in a sandbox before production deployment
- Phase your migration by business function or object to minimize risk
- Deactivate legacy processes only after confirming new flows work identically
Your next step is to run a complete inventory of your org's Process Builder processes today. The salesforce process builder retirement date end of support is already your reality — every day you delay migration adds technical debt and risk. Identify your simplest process, run the Migrate to Flow tool on it in a sandbox, and validate the results.
Each successful migration builds confidence and momentum for the larger effort ahead.
