Automated Actions
An Automated Action in Salesforce is a reusable side effect that an automation rule fires when its trigger conditions are met.
Definition
An Automated Action in Salesforce is a reusable side effect that an automation rule fires when its trigger conditions are met. The classic catalog has four types: a Field Update changes a value on the triggering record or a parent record, an Email Alert sends an outbound email from a template, a Task creates an assigned activity, and an Outbound Message posts a SOAP message to a configured external endpoint. Each action is its own metadata record. You build it once in Setup, then point one or more rules at it.
The concept predates Flow and is tied to the older automation tools. Workflow Rules and Process Builder both reached end of support on December 31, 2025, so they no longer get bug fixes or Salesforce support, though existing rules keep running. Approval Processes still expose these actions, and legacy Workflow Rule actions continue to fire in older orgs. New automation should use Flow, whose action list is much wider than the original four.
The four Automated Action types and where they still live
Field Update: rewriting a value when conditions match
A Field Update Action sets a new value on a field of the triggering record, and in some cases a related parent record. Admins used Field Updates constantly for status transitions, stamping owner changes, copying values down a hierarchy, and forcing formula fields to recalculate. The action is configured in Setup with a target object, a target field, and the new value, which can be a literal, a blank, or a formula. One important option is Re-evaluate Workflow Rules after Field Change. When that box is checked, updating the field re-runs every Workflow Rule on the object, which can trigger a second pass of actions. That behavior is the most common cause of looping automation in legacy orgs, so it deserves a careful look during any review. Field Updates run inside the same transaction as the rule that fired them, so they do not count as a separate DML statement against the parent operation in the way a fresh record save would. In modern Flow, the equivalent is the Update Records element, which can update the triggering record, related records, or any set of records returned by a Get element. Fast Field Updates in a before-save record-triggered flow run far faster than a Workflow Rule field update because they avoid a second save.
Email Alert: sending a templated email to a recipient set
An Email Alert Action sends an email built from a chosen Email Template to a defined recipient list. Recipients can be specific users, a role, a public group, a queue, the record owner, or an email address stored in a field on the record. You configure the template, the from address, and the recipients once, then reuse the alert across rules. Email Alerts share the daily workflow email limit, which caps the number of alert emails an org can send per day based on its edition and user count. Alerts that exceed the limit are dropped, so high-volume automation needs to account for the cap. A subtle trap is addressing an alert to the running user. When automation chains together, the same person can receive a surprising number of notifications. Flow keeps backward compatibility here: a flow can call an existing Email Alert directly through the Action element, so you do not have to rebuild templates during migration. Flow also offers a richer Send Email action and Send Email Notification options for in-app alerts, which give more control over content and formatting than the legacy alert.
Task: creating an assigned activity record
A Task Action creates a new Task record and assigns it to a chosen user, the record owner, a related user looked up through a lookup field, or in some cases a queue. The admin sets the subject, due date offset, status, priority, and a few standard fields when configuring the action. Task Actions were the standard way to remind a sales rep to follow up, prompt a service agent to call back, or queue a review step after a record changed state. Because a Task is just a record, the modern equivalent is a Create Records element in Flow that builds an activity. Flow gives you more flexibility: you can set any field, create the task only when a decision branch is met, and create several tasks in a loop. One thing to watch when migrating is the due date. Legacy Task Actions express the due date as an interval relative to the trigger date, such as seven days after the rule fires. In Flow you recreate that with a formula that adds the interval to TODAY. Reviewing converted tasks for the right offset avoids quietly shifting every reminder by a day.
Outbound Message: a SOAP callout to an external endpoint
An Outbound Message Action sends a SOAP message to an external web service when a rule fires. You configure the endpoint URL, the user whose session id is included, and the list of fields to send. Salesforce posts an XML payload to the endpoint and, if asked, retries on failure for up to 24 hours. The pattern was a common way to push record changes to a middleware layer or an external system before richer integration tools existed. It is brittle by modern standards. The receiving service must implement the generated WSDL, and failures are easy to miss because there is no built in alerting beyond the retry queue. Outbound Messages can be created from Workflow Rules, from Approval Processes, and historically from Process Builder. Existing ones keep working, but new integrations should not add them. The modern replacement is Flow combined with an HTTP Callout action or an External Service, which speaks REST, supports fault paths, and lets you log the result. Platform Events and Change Data Capture are better fits when you want a decoupled, event-driven push instead of a synchronous callout.
Which tools can fire these actions
Automated Actions never run on their own. A rule has to invoke them. Workflow Rules attached actions either immediately when the record met the criteria or on a time-based trigger scheduled for the future. Approval Processes attach actions to specific points: initial submission, each approval step, final approval, final rejection, and recall. Those approval-attached actions are why the concept survives even after Workflow Rules lost support. Process Builder reused the same four action types and added more, including invoking Apex, posting to Chatter, and submitting a record for approval. Flow inherited and extended that wider list with Apex Actions, External Services, HTTP Callouts, subflows, and platform-specific actions. The practical takeaway is that the original four-action menu is a subset of what Flow can do. When you see Field Update, Email Alert, Task, or Outbound Message in an org, you are looking at either a Workflow Rule, an Approval Process, or a Process Builder that has not been migrated yet.
Why Salesforce consolidated automation in Flow
For years admins juggled three declarative tools that each had a separate canvas, a separate action catalog, and separate runtime behavior. A field change might fire a Workflow Rule, a Process Builder, and a record-triggered flow, with no single place to see the order or debug a failure. Salesforce decided to focus low-code automation on Flow Builder, which has one canvas, one debugger, and the broadest action set. Workflow Rules and Process Builder reached end of support on December 31, 2025. They keep running, but they no longer receive bug fixes or support, and you cannot create new Workflow Rules in newer orgs. Flow also performs better. A before-save flow that does Fast Field Updates runs roughly ten times faster than a Workflow Rule field update because it skips the extra save. Approval Processes were not retired and still use the classic actions, so the Automated Actions surface has not disappeared entirely. It is simply no longer where new work should start.
Migrating Automated Actions to Flow
Salesforce ships a Migrate to Flow tool in Setup that converts Workflow Rules, and most Process Builder processes, into record-triggered flows. The tool maps each legacy action to a Flow element. Field Updates become Update Records elements, Email Alerts become calls to the same Email Alert through an Action element, Tasks become Create Records elements, and Outbound Messages are carried over where supported. After conversion you can test the new flow in Flow Builder, then use Switch Activations to deactivate the old rule and activate the flow in one step. The tool now supports partial migration for most action types, so even a rule it cannot fully convert can be moved in pieces. A sensible approach is to migrate one rule, verify the flow in a sandbox, and keep the deactivated original around for a release in case you need to roll back. Deletion is irreversible, while deactivation is not, so do not delete legacy automation the moment the flow goes live. Complex rules with chained Field Updates or time-based actions usually need manual cleanup after the automated pass.
How to build and attach an Automated Action
You configure an Automated Action once in Setup, then attach it to a Workflow Rule or an Approval Process. This walkthrough creates a reusable Email Alert, which is the most common action type. The same Setup path covers Field Updates, Tasks, and Outbound Messages.
- Open the action area in Setup
From Setup, use Quick Find to locate the action type. Email Alerts, Field Updates, Tasks, and Outbound Messages each have their own Setup node, and they are also reachable while editing a Workflow Rule or Approval Process.
- Create the action and pick the object
Click New, give the action a clear name and unique name, and select the object it acts on. The object choice limits which fields, templates, and recipients are available later.
- Fill in the action details
For an Email Alert, choose the Email Template, set the from address, and add recipients such as the owner, a role, a queue, or an email field on the record. For a Field Update you would instead pick the target field and new value.
- Attach the action to a rule
Open a Workflow Rule or Approval Process and add the saved action to the immediate actions, a time-dependent trigger, or an approval step. The same action record can be referenced by more than one rule.
The template an Email Alert uses for subject and body. Build it before creating the alert so it appears in the picker.
Who receives the Email Alert: users, roles, public groups, queues, the record owner, or an email field on the record.
A Field Update option that re-runs every Workflow Rule on the object after the change. Leave it off unless you truly need cascading evaluation.
For an Outbound Message, the external service address that receives the SOAP payload. The receiver must implement the generated WSDL.
- Email Alerts share a daily workflow email limit; alerts beyond the cap are silently dropped.
- Field Updates with Re-evaluate Workflow Rules turned on are the top cause of looping automation.
- Outbound Messages fail quietly when the endpoint is down; there is no alerting beyond the retry queue.
- You cannot create new Workflow Rules in newer orgs, so plan the action inside Flow or an Approval Process instead.
Trust & references
Cross-checked against the following references.
- Workflow Rules and Process Builder End of SupportSalesforce
- Email Alert ActionsSalesforce
Straight from the source - Salesforce's reference material on Automated Actions.
Hands-on resources to go deeper on Automated Actions.
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. What are the four classic Automated Action types?
Q2. Which tools use Automated Actions?
Q3. What is the modern replacement for classic Automated Actions?
Discussion
Loading discussion…