Retired Automation Processes in Salesforce: Workflow Rules and Process Builder

Part 25: Retired Automation Processes in Salesforce — Workflow Rules and Process Builder

Before Salesforce Flows became the unified automation platform, administrators relied on two primary declarative automation tools: Workflow Rules and Process Builder. These tools served the Salesforce ecosystem well for over a decade, but Salesforce has officially retired them in favor of Flow Builder. Understanding what these tools did, how they worked, and why they were replaced is essential — both for maintaining legacy orgs and for appreciating how far Salesforce automation has come.

In this part, we will cover what Workflow Rules and Process Builder are, walk through how each was created, examine why Salesforce is retiring them, and discuss how to migrate your existing automations to Flows.

Why Is Salesforce Retiring These Tools?

Salesforce announced the retirement of Workflow Rules and Process Builder as part of a broader strategy to consolidate all declarative automation under a single tool: Flow Builder. Here is the timeline of key announcements and changes:

• Spring ‘22: Salesforce announced that Workflow Rules and Process Builder would no longer receive new feature updates. All future investment would go into Flow Builder.
• Winter ‘23: Salesforce disabled the ability to create new Workflow Rules in newly provisioned orgs.
• Spring ‘23: Salesforce disabled the ability to create new Process Builder processes in newly provisioned orgs.
• Ongoing: Existing Workflow Rules and Process Builder processes continue to function in orgs where they already exist, but Salesforce strongly recommends migrating them to Flows.

The reasoning behind retirement is straightforward:

1. Fragmented tooling — Having three separate automation tools (Workflow Rules, Process Builder, and Flow) confused administrators and made it difficult to troubleshoot automation order of execution issues.
2. Limited capabilities — Workflow Rules and Process Builder had significant limitations compared to Flows (no loops, limited decision logic, no screen interactions).
3. Performance concerns — Process Builder in particular was known for causing performance issues due to how it handled multiple criteria nodes and re-evaluation.
4. Maintenance overhead — Salesforce maintaining three separate automation engines created unnecessary engineering overhead.
5. Unified debugging — With everything in Flow, administrators can use a single debug tool and a single order of execution model.

Workflow Rules

What Are Workflow Rules?

Workflow Rules were one of the earliest declarative automation tools in Salesforce. A Workflow Rule evaluates a record when it is created or edited and, if the record meets certain criteria, executes one or more automated actions. Think of them as simple “if this, then that” automations tied to a single object.

What Could Workflow Rules Do?

Workflow Rules supported exactly four types of automated actions:

1. Field Updates — Automatically update a field value on the current record or a related parent record (via a lookup relationship). For example, setting a Status field to “Approved” when certain conditions are met.

2. Email Alerts — Send a pre-defined email template to specified recipients when the rule fires. These used Email Alert actions tied to email templates.

3. Outbound Messages — Send a SOAP-based XML message to an external endpoint. This was an early form of integration, allowing Salesforce to notify external systems when a record met certain conditions.

4. Tasks — Automatically create a Task record and assign it to a user, role, or record owner. For example, creating a follow-up task when an Opportunity reaches a certain stage.

Workflow Rules also supported Time-Dependent Actions, which allowed you to schedule any of the above four actions to execute at a future time relative to a date field on the record (e.g., 3 days before the Close Date, or 1 hour after creation).

Workflow Rule Evaluation Criteria

When creating a Workflow Rule, you had to choose when the rule should evaluate the record. There were three options:

1. Created — The rule evaluates only when a record is first created. If the record meets the criteria at the time of creation, the actions fire. The rule never evaluates the record again on subsequent edits.

2. Created, and every time it’s edited — The rule evaluates every time the record is created or edited. If the record meets the criteria, the actions fire. This means actions could fire repeatedly on every save, which was useful for field updates that should always enforce a value but problematic if you were sending email alerts (you could end up sending duplicate emails).

3. Created, and any time it’s edited to subsequently meet criteria — The rule evaluates every time the record is created or edited, but the actions only fire when the record transitions from not meeting the criteria to meeting the criteria. This was the most commonly used option because it prevented actions from firing repeatedly. Once the record met the criteria and actions fired, they would not fire again unless the record first stopped meeting the criteria and then met it again.

How to Create a Workflow Rule (Step-by-Step)

Even though you can no longer create new Workflow Rules in most orgs, understanding the process helps when you encounter them in legacy systems:

1. Navigate to Setup and search for Workflow Rules in the Quick Find box.
2. Click New Rule.
3. Select the Object the rule applies to (e.g., Opportunity, Case, Account).
4. Give the rule a Rule Name and optionally a description.
5. Set the Evaluation Criteria — choose one of the three options described above.
6. Define the Rule Criteria — either use field-based filter criteria (field, operator, value) or write a formula that evaluates to true.
7. Click Save & Next.
8. Add Workflow Actions — choose from Immediate Actions (fire right away) or Time-Dependent Actions (fire at a scheduled time).
   • For Immediate Actions: Click Add Workflow Action and select New Field Update, New Email Alert, New Outbound Message, or New Task.
   • For Time-Dependent Actions: Click Add Time Trigger, define the time offset (e.g., 7 days before Close Date), then add actions under that time trigger.
9. Click Done.
10. Back on the Workflow Rule detail page, click Activate to turn the rule on.

Limitations of Workflow Rules

• Could only perform four types of actions.
• Could not perform actions on unrelated objects (only the current record or a parent via lookup).
• No branching or decision logic — just a single if/then evaluation.
• No looping or iteration.
• Could not create or delete records (except Tasks).
• Could not call Apex or invoke external services (except via Outbound Messages).
• Could not post to Chatter, submit for approval, or perform other complex actions.

Process Builder

What Is Process Builder?

Process Builder was introduced as the next evolution of declarative automation in Salesforce. It offered a visual, flowchart-style interface and significantly expanded what administrators could automate without code. Process Builder was more powerful than Workflow Rules and was intended to eventually replace them — before Flows replaced both.

What Could Process Builder Do?

Process Builder supported a much wider range of actions than Workflow Rules:

• Create a Record — Create a new record on any object.
• Update Records — Update fields on the current record, related records, or any record found via criteria.
• Email Alerts — Send email alerts using email templates.
• Post to Chatter — Automatically post a message to a Chatter feed.
• Submit for Approval — Submit the current record to an approval process.
• Launch a Flow — Invoke an autolaunched Flow, passing values in and out.
• Call Apex — Invoke an Apex class that implements the Invocable interface.
• Send Custom Notification — Send a custom notification to specific users.
• Quick Actions — Execute object-specific or global quick actions.

Process Builder Architecture

A Process Builder process consisted of:

1. A Trigger — Defined what started the process. Options were:

   • A record changes (record-triggered — the most common).
   • It receives a platform event message.
   • It is invoked by another process.

2. Criteria Nodes — One or more decision points that evaluated whether the record met certain conditions. Each criteria node had:

   • Criteria Name — A descriptive label.
   • Conditions — Field-based filters or a formula.
   • Condition Logic — AND, OR, or custom logic combining conditions.
   • Do you want to execute the actions only when specified changes are made? — Yes (only when changes cause criteria to be met for the first time) or No (every time conditions are met).

3. Actions — Under each criteria node, you defined the actions to perform if that criteria was met. You could have multiple actions per criteria node.

4. Evaluation Flow — Process Builder evaluated criteria nodes from top to bottom. Once a criteria node was met, its actions executed. You could choose whether to stop after the first match or continue evaluating subsequent criteria nodes.

How to Create a Process Builder Process (Step-by-Step)

1. Navigate to Setup and search for Process Builder in the Quick Find box.
2. Click New.
3. Enter a Process Name, API Name, and optional description.
4. Choose the trigger type: A record changes, It receives a platform event, or It is invoked by another process.
5. Click Save.
6. On the canvas, click Add Object (for record-triggered processes):
   • Select the Object.
   • Choose when to start the process: only when a record is created or when a record is created or edited.
   • Click Save.
7. Click Add Criteria:
   • Enter a Criteria Name.
   • Set the Criteria for Executing Actions: choose “Conditions are met,” “Formula evaluates to true,” or “No criteria — just execute the actions.”
   • If using conditions, define field filters and choose AND/OR/custom logic.
   • Choose whether to execute actions only when changes meet criteria or every time criteria are met.
   • Click Save.
8. Under the criteria node, click Add Action:
   • Select the Action Type (e.g., Update Records, Create a Record, Email Alerts).
   • Configure the action details.
   • Click Save.
9. Optionally add more criteria nodes by clicking Add Criteria below the existing one. You can add a Schedule to actions under any criteria node to make them time-dependent.
10. Click Activate to turn the process on.

Limitations of Process Builder

• Performance issues — Process Builder was notorious for performance problems. Each criteria node could cause the record to be re-evaluated, and complex processes with many nodes could slow down save operations significantly.
• No loops — Could not iterate over a collection of records.
• No screens — Could not present a user interface to the user.
• Difficult debugging — Error messages were often vague, and there was no built-in debug tool like Flow has.
• Bulkification concerns — Process Builder did not always handle bulk operations efficiently, leading to governor limit issues during data loads.
• Order of execution complexity — Having multiple active Process Builder processes on the same object could lead to unpredictable behavior and difficult-to-trace bugs.

Comparison Table: Workflow Rules vs Process Builder vs Flows

Why Flows Are Better

Flows consolidate and surpass everything that Workflow Rules and Process Builder could do, and add substantially more:

• Before-Save Flows — Update fields on a record before it is saved to the database, avoiding an extra DML operation. Neither Workflow Rules nor Process Builder could do this.
• Loops and Collections — Iterate over collections of records, enabling bulk processing within a single automation.
• Screen Flows — Present interactive screens to users, gathering input and guiding them through multi-step processes.
• Subflows — Call other Flows as building blocks, promoting reusability and modular design.
• Record-Triggered Flows with Multiple Paths — Handle complex branching logic with decision elements and fault paths.
• Debugging — Flow Builder includes a robust debug tool that lets you step through each element, see variable values, and identify exactly where failures occur.
• Transaction Control — Better handling of DML operations and governor limits.
• Platform Event Triggers — Respond to platform events natively.
• Scheduled Triggered Flows — Run on a schedule against a batch of records meeting specific criteria.
• HTTP Callouts — Make external API calls directly from a Flow without Apex.
• Custom Error Messages — Display specific error messages to users when validation or business logic fails.

In short, there is nothing that Workflow Rules or Process Builder could do that Flows cannot do — and Flows can do significantly more.

The Migrate to Flow Tool

Salesforce provides a built-in Migrate to Flow tool to help administrators convert their existing Workflow Rules and Process Builder processes into Flows. Here is how to use it:

For Workflow Rules

1. Navigate to Setup and search for Workflow Rules.
2. Find the Workflow Rule you want to migrate.
3. Click the Migrate to Flow button next to the rule (or on the rule detail page).
4. Salesforce generates an equivalent Record-Triggered Flow in draft status.
5. Review the generated Flow in Flow Builder — check that all criteria, actions, and time-dependent actions were correctly translated.
6. Test the Flow thoroughly using the debug tool.
7. Activate the Flow.
8. Deactivate the original Workflow Rule.

For Process Builder

1. Navigate to Setup and search for Process Builder.
2. Open the process you want to migrate.
3. Click the Migrate to Flow button.
4. Salesforce generates one or more Record-Triggered Flows based on the process criteria and actions.
5. Review each generated Flow carefully — Process Builder processes with multiple criteria nodes may produce multiple Flows or a single Flow with multiple decision branches.
6. Test each Flow using the debug tool.
7. Activate the Flows.
8. Deactivate the original Process Builder process.

Tool Limitations

The Migrate to Flow tool does a good job with straightforward automations, but it is not perfect:

• Complex processes with many criteria nodes may not convert cleanly.
• Some action types may require manual adjustment after migration.
• Time-dependent actions are converted to Scheduled Paths, which behave slightly differently.
• Invocable Apex calls should be verified to ensure they still work correctly in the Flow context.
• The tool may not handle cross-object field references exactly the same way.

Always test migrated Flows thoroughly before deactivating the original automation.

Migration Strategy and Best Practices

Migrating an org’s worth of Workflow Rules and Process Builder processes to Flows requires a systematic approach:

1. Inventory Your Automations

Start by cataloging every Workflow Rule and Process Builder process in your org. Document:

• What object each automation runs on.
• What actions each automation performs.
• Whether the automation is active or inactive.
• How critical the automation is to business operations.

2. Prioritize by Risk and Complexity

• Low complexity, high usage — Migrate these first. They are usually straightforward to convert and give you quick wins.
• High complexity, high usage — Migrate these carefully with thorough testing.
• Inactive automations — Consider whether these are still needed. If not, do not migrate them. Simply document and archive.

3. Consolidate Where Possible

One of the biggest advantages of migrating to Flows is the opportunity to consolidate. If you have five Workflow Rules and two Process Builder processes on the Account object, you may be able to replace all seven with a single Record-Triggered Flow using multiple decision paths. This simplifies maintenance and reduces order-of-execution conflicts.

4. Test in a Sandbox First

Never migrate directly in production. Always:

• Migrate in a full or partial sandbox.
• Test with real-world data scenarios.
• Run the Flow debug tool on various record creation and update scenarios.
• Verify that email alerts, field updates, and record creations behave identically to the original automation.

5. Deactivate, Don’t Delete

After migrating and verifying a Flow works correctly, deactivate the original Workflow Rule or Process Builder process — do not delete it immediately. Keep it available for a rollback period (e.g., 30 days) in case issues are discovered in production.

6. Communicate with Stakeholders

Let your team know that automations are being migrated. Even though the end-user behavior should be identical, having the team aware means they can report any anomalies quickly.

What Happens to Existing Workflow Rules and Process Builder Processes?

This is a common source of confusion, so let us be clear:

• Existing active Workflow Rules continue to run. If you have Workflow Rules that were created and activated before the retirement, they will keep functioning as they always have.
• Existing active Process Builder processes continue to run. Same as above — already-active processes are not affected.
• You cannot create new Workflow Rules or Process Builder processes in orgs provisioned after the retirement dates (and Salesforce is progressively rolling this out to older orgs as well).
• You can still edit existing Workflow Rules and Process Builder processes in most orgs, though Salesforce may restrict this in the future.
• Salesforce has not announced a date when existing automations will stop running. However, the strong recommendation is to migrate proactively rather than waiting for a forced cutoff.

Common Migration Gotchas

Here are pitfalls that administrators frequently encounter when migrating from Workflow Rules and Process Builder to Flows:

1. Order of Execution Changes — Workflow Rules run at a specific point in the Salesforce order of execution (after before triggers, after the record is saved, but before after triggers complete). Record-Triggered Flows can run before save or after save. Make sure your migrated Flow runs in the correct context.

2. Re-evaluation Behavior — Workflow Rules with the “Created, and every time it’s edited” evaluation criteria fire on every edit. A Record-Triggered Flow’s entry conditions work differently. Ensure you configure the Flow’s entry conditions to match the original behavior.

3. Cross-Object Field Updates — Workflow Rules could update a parent record’s field via a lookup. In Flows, you need an explicit Update Records element targeting the parent. The Migrate to Flow tool usually handles this, but verify it.

4. Time-Dependent Actions vs Scheduled Paths — Workflow Rule time-dependent actions and Flow Scheduled Paths have subtle differences. In particular, if the record no longer meets the criteria when the scheduled time arrives, the behavior may differ. Test these scenarios carefully.

5. Email Alert Recipients — Verify that migrated email alerts go to the same recipients. The Migrate to Flow tool sometimes sets up the email alert action slightly differently.

6. Process Builder Recursion — Process Builder had a checkbox for “Allow process to evaluate a record multiple times in a single transaction.” Flows handle recursion differently using the “Run the flow when a record is updated” entry criteria. Misconfiguring this can lead to infinite loops or missed executions.

7. Governor Limits — A Flow that replaces multiple Workflow Rules or Process Builder processes may consume more SOQL queries or DML operations in a single transaction if not optimized. Use before-save Flows for field updates where possible to reduce DML usage.

8. Bulk Data Loads — If your org processes large data loads (via Data Loader, imports, or integrations), test the migrated Flow with bulk operations. Flows generally handle bulk better than Process Builder, but poorly designed Flows can still hit limits.

9. Test Coverage — If your migration involves any Apex invocable actions, ensure your test classes still cover the Apex code when invoked from a Flow context rather than a Process Builder context.

10. Approval Process Dependencies — If a Process Builder process submitted records for approval, make sure the migrated Flow’s “Submit for Approval” action is configured with the correct approval process name and submitter settings.

Section Notes

• Workflow Rules and Process Builder are legacy tools. If you are starting fresh, go directly to Flow Builder. There is no reason to learn these tools for new development.
• If you are studying for a Salesforce certification, you may still encounter questions about Workflow Rules and Process Builder. Understanding their capabilities and limitations remains relevant for exam purposes.
• The Migrate to Flow tool is continually improving. Check the Salesforce release notes for the latest updates on migration capabilities.
• When maintaining a legacy org, document every automation you find — including Workflow Rules, Process Builder processes, and Flows. An automation inventory is invaluable for understanding system behavior and preventing conflicts.
• Salesforce’s official recommendation is clear: migrate everything to Flows as soon as practically possible. The sooner you do, the sooner you benefit from better debugging, better performance, and a unified automation platform.

That wraps up Part 25 of the Salesforce series. Workflow Rules and Process Builder served the platform well, but their time has passed. Flows represent the present and future of Salesforce declarative automation. If your org still relies on these legacy tools, prioritize migration — the tools and guidance are available, and the benefits are substantial.

In the next part, Part 26, we will cover Deploying Changes to Production — the critical process of moving your configurations, customizations, and automations from sandbox environments into your live production org. See you there!