Salesforce Automation in 2026: Flow, Apex, Approvals and Agentforce

What Is Salesforce Automation?

Salesforce automation is any rule, flow, trigger or agent that does work in Salesforce when something happens, on a schedule, or when a user or system asks. It handles the repeatable steps people would otherwise do by hand: assigning a lead, updating a field, creating a follow-up record, emailing a customer, requesting approval or calling another system.

It helps to separate two meanings of the phrase. "Sales force automation" (SFA) is the older industry term for CRM software that automates the sales process. This article is about platform automation: the tools inside Salesforce you use to build those processes for sales, service, marketing and operations teams.

Every automation answers three questions:

• When does it start? A record is created, updated or deleted; a time arrives; a platform event fires; a user clicks a button; or an AI agent decides to act.
• What should it check? Entry conditions that decide whether this record, at this moment, needs the automation.
• What does it do? Update fields, create or update related records, send emails or notifications, start an approval, call Apex or call an external system.

Which Salesforce Automation Tools Should You Use in 2026?

Build new automation in Flow Builder. Use Apex when volume or complexity outgrows Flow, Flow Approval Processes for approvals, and Flow Orchestration for multi-step work involving several people. Assignment, auto-response and escalation rules still do their narrow jobs well. Agentforce agents sit on top, calling flows and Apex as actions. Here is the toolkit as Salesforce documents it in the Winter '27 release.

Sources: Salesforce Help on flow types, Flow Approval Processes, Flow Orchestration and assignment rules, plus the Winter '27 automation release notes.

What Happened to Workflow Rules and Process Builder?

Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025. Your active rules and processes keep running, and you can still edit, activate and deactivate them. What changed is that Salesforce no longer provides customer support or bug fixes for either feature, and it recommends building all new automation in Flow Builder.

Salesforce's end-of-support article gives the reason plainly: it wants to focus development on one modern, extensible, low-code automation tool, and Flow Builder is that tool. The help pages now file Workflow Rules and Process Builder under "Legacy Salesforce Flow Features".

How to find what you still have: in Setup, open Process Automation > Workflow Rules and sort by the Active column, then open Process Automation > Process Builder and sort by Status. That list is your migration backlog.

How Do You Migrate Workflow Rules and Process Builder to Flow?

Inventory what is active, rationalise it, convert it with the Migrate to Flow tool in a sandbox, rebuild what the tool cannot convert, then test, activate the flow and deactivate the original. The tool handles a lot, but not everything. Treat the migration as a chance to consolidate automation, not just copy it one-for-one.

According to Salesforce's Migrate to Flow considerations, processes become after-save flows (you can re-optimise them for fast field updates afterwards), and workflow rules that only update fields become before-save flows. These are the limits most likely to catch you out:

Salesforce Flow vs Apex: How Do You Choose?

Use Flow for most record-triggered automation. Add invocable Apex when a flow needs logic that is hard to express declaratively, and move an object to an Apex trigger framework when its automation is dense: many automations, large record volumes and long chains of downstream updates. That is the recommendation of Salesforce's own architects.

The Record-Triggered Automation decision guide, updated in March 2026, describes Flow and Apex triggers as "two complementary pillars" and calls record-triggered flow "the ideal choice for most teams". It chooses between them by automation density: the number of automations on an object, the record volumes they handle and how many downstream updates each one sets off.

Thresholds from the decision guide. Whatever the density, the guide recommends one entry point per object, so all of an object's record-triggered logic runs in a predictable order.

A published Twopir project shows the split in practice. For an enterprise SaaS operations team re-keying form submissions by hand, Flow handled routing, owner assignment and confirmation emails, while custom Apex handled duplicate detection and matching. The case study reports zero manual data-entry steps remaining and duplicate-safe record creation across Lead, Contact and Case.

Which Record-Triggered Flow Option Should You Use?

Use a before-save flow (Fast Field Updates) when you only change fields on the record that triggered the flow. Use an after-save flow (Actions and Related Records) to touch other records or send alerts, an asynchronous path for callouts, and a scheduled path for work that should happen later. Choosing the right option is the single biggest performance lever in Flow.

Salesforce's help states that a record-triggered flow can update a record 10 times faster than a record-change process when it uses a before-save update, because the change is made before the save and needs no second database operation.

Details from Salesforce Help on record-triggered flow considerations and scheduled paths. Scheduled paths run in system context and use asynchronous limits; you can see pending items under Setup > Time-Based Automations.

How Do ISNEW, ISCHANGED and PRIORVALUE Work in Salesforce Flow?

ISNEW() is true while a record is being created, ISCHANGED() is true when a field's value differs from before, and PRIORVALUE() returns a field's previous value. Since the Summer '21 release, record-triggered flows for new and updated records support all three in formulas, written against $Record. Flow also offers $Record__Prior and an entry option that fires only when a record changes into your conditions.

Our 2022 version of this article showed these functions inside workflow rules. They are just as useful now, but how you use them in Flow is different. The Summer '21 release note explains the syntax change: ISCHANGED(Account.Rating) in a process becomes ISCHANGED({!$Record.Rating}) in a flow. None of the three are available in flows that run when a record is deleted.

Three patterns worth copying

• Catch creation and later changes in one flow. If a flow runs when a record is created or updated, the Is Changed operator will not fire on create, because a new record has no prior value. Salesforce's knowledge article recommends an entry formula such as OR(ISNEW(), ISCHANGED({!$Record.Status})), or two separate flows.
• React to a specific transition. To act only when an opportunity moves from Negotiation to Closed Won, check {!$Record__Prior.StageName} as well as the new value. The global variables reference documents $Record__Prior for flows that run on update, or on create and update.
• Stop flows that run on every save. Salesforce warns that a flow with no entry conditions runs on every record change and can exceed governor limits. The "only when updated to meet the conditions" option runs a flow once, when a record moves into your conditions, which also prevents most recursion.

One documentation nuance: Salesforce's general flow formula considerations list PRIORVALUE as unsupported in flow formula resources. For old-versus-new comparisons in a record-triggered flow, $Record__Prior is the documented, dependable route. Outside Flow, ISNEW, ISCHANGED and PRIORVALUE still work in validation rules and assignment rules.

Classic Approval Processes or Flow Approval Processes?

For new approvals, use Flow Approval Processes. Salesforce positions them as the modern alternative to Classic Approval Processes, with record-triggered starts, dynamic routing based on data and business rules, Apex extensibility and detailed logging. Classic Approval Processes are still available and no end of support has been announced, but Salesforce now files them under its legacy features.

A flow approval process is built in Flow Builder as a sequence of stages. Each stage holds approval steps that assign work to a user, group or queue, and background steps that run without anyone's input. Approvers can reply to the approval email with a keyword, and the process can start when a record is submitted or when a qualifying record is created or updated. Salesforce's approvals overview notes one case where there is no choice: approvals on the User object are only possible with Flow Approval Processes.

The Winter '27 release adds a Request Approvals component that puts up to 10 flow approval processes on a record page, and lets admins delete approval submission records to meet GDPR and other compliance requirements.

Flow Orchestration goes a step further for processes that cross teams. An orchestration is a sequence of stages, each with interactive steps (a screen flow assigned to a person) and background steps (an autolaunched flow). Salesforce suggests it for advanced approval processes, task lists for groups and other multi-step processes, such as customer onboarding that involves sales, finance and implementation.

What Are Good Salesforce Automation Examples for Each Team?

The best first automations are frequent, rule-based and currently done by hand: routing leads and cases, creating follow-up work, reminding people about deadlines, requesting approvals and syncing data with finance or marketing systems. These examples show which tool usually fits each job in a typical growing or mid-market org.

The thresholds above (14 days, 90 days) are illustrations, not recommendations: set yours from your own sales cycle and contract terms. For routing in Service, Salesforce allows one active rule of each type (assignment, auto-response and escalation) at a time, with limits on rules and entries that matter in larger orgs.

Where Does Agentforce Fit in Salesforce Automation?

Agentforce agents decide what to do; flows and Apex do it. An agent can read Salesforce data, but it changes data only through agent actions, and those actions call flows, Apex or prompt templates. A well-built automation layer is what makes an agent useful, which is why automation clean-up usually comes before an AI project.

Trailhead's guide to agent-ready flows sets out the rules. Agent actions support only autolaunched flows with no trigger. The flow's description becomes an instruction the agent reads when deciding whether to use it. Each action needs clear input and output variables, and Salesforce advises many small flows rather than one large one. The Agent Script actions reference adds an optional user-confirmation step before an action runs.

• Write descriptions as if an agent will read them, because it will. The decision guide calls element descriptions "critical for AI and agent-based tools".
• Keep the logic in reusable subflows. The same autolaunched flow can serve a button, a record-triggered flow and an agent action.
• Keep people in the loop for important steps. Flow Approval Processes and user confirmation on agent actions let agents propose and people approve.

Flow Builder is gaining AI help too: Winter '27 adds Flow Author (beta) for building flows through conversation, and Salesforce Help describes using Agentforce to troubleshoot flow errors. For the wider picture, see our guide to AI-powered tools in Salesforce. Our Agentforce automation services cover the flows, Apex, approvals, routing and integrations an agent needs to finish the work it starts.

What Are the Best Practices for Salesforce Automation?

Plan before you build, give each object one predictable entry point, use precise entry conditions, keep database operations out of loops, add fault paths, test every path in a sandbox, and document every flow. These habits come straight from Salesforce's Flow best practices and the architects' decision guide.

1. 1

   Control the order. Use Flow Trigger Explorer to see every record-triggered flow on an object and set its Trigger Order. Avoid both extremes: dozens of unordered flows, or one "mega-flow" that the decision guide calls an anti-pattern.

2. 2

   Use precise entry conditions. Run a flow only when it has work to do. The decision guide names before-save flows and precise entry conditions as the biggest performance gains.

3. 3

   Keep database work out of loops. Flow batches interviews automatically, but a Create Records element inside a loop still performs one DML operation per pass. Collect records in the loop and save them once at the end, as Salesforce's bulkification guidance explains.

4. 4

   Add fault paths everywhere that can fail. Send a useful message to users and an alert with details to the admin team, instead of "An unhandled fault has occurred in this flow". Our post on fault path strategies goes deeper.

5. 5

   Respect governor limits. Flows share Apex's per-transaction limits, including 100 SOQL queries, 150 DML statements and 10,000 ms of CPU time. If a limit is exceeded, the whole transaction rolls back, even where a fault path exists.

6. 6

   Test in a sandbox, every path. Build flow tests for record-triggered and autolaunched flows. Winter '27 adds Flow Test Mode (beta), with mock outputs for Action and Subflow elements.

7. 7

   Never hard-code record IDs, and document everything. Use clear labels, API names and descriptions, keep flows in source control, and give admins a custom permission to bypass automation during data loads.

Most automation problems we are asked to fix come from overlap: a workflow rule, a process, two flows and an Apex trigger all updating the same object. A Salesforce health check maps what runs where before anything is changed.

The Bottom Line on Salesforce Automation

Salesforce automation has settled into a clear shape: Flow for most work, Apex for dense or complex objects, Flow Approval Processes and Flow Orchestration for work involving several people, and Agentforce agents that act through all of them. The legacy tools still run, but every month they stay in place adds risk and makes the next change harder.

1. 1

   Inventory your active Workflow Rules and Process Builder processes, and plan their move to Flow.

2. 2

   Choose Flow or Apex per object by automation density, with one entry point per object.

3. 3

   Use before-save flows for same-record updates and precise entry conditions everywhere.

4. 4

   Use $Record__Prior, ISNEW and ISCHANGED to run automation only when something meaningful changes.

5. 5

   Build small, well-described autolaunched flows that people, processes and AI agents can all reuse.

Frequently Asked Questions