Approval Action
An Approval Action in Salesforce is an automated action that an Approval Process runs at a defined point in its lifecycle.
Definition
An Approval Action in Salesforce is an automated action that an Approval Process runs at a defined point in its lifecycle. Those points are when a record is first submitted, when an individual step is approved or rejected, when the whole process finishes with approval or rejection, and when the submitter recalls the request. Each action performs a side effect, such as updating a field, sending an email alert, creating a task, sending an outbound message, or running a flow. Approval Actions are what turn a human decision into changes the rest of the org can see.
Approval Actions are configured inside the Approval Process editor, attached to one of five trigger points: Initial Submission Actions, Approval Step Actions, Final Approval Actions, Final Rejection Actions, and Recall Actions. Any trigger point can hold any number of actions. The Salesforce documentation lists the same five action types at each point: email alert, field update, task, outbound message, and flow. Most real processes lean on field updates and email alerts, with record locking handled automatically on submission and unlocked when the process resolves.
How Approval Actions fit into the approval lifecycle
The five action types you can attach
Salesforce supports the same five automated action types across approval triggers. A field update changes a field value on the submitted record, and in some cases on a parent record reached through a master-detail relationship. An email alert sends an outbound email built from an email template, to recipients you choose. A task creates an assigned Task record so someone has a follow-up to work. An outbound message posts a SOAP message to a configured external endpoint. A flow action runs an autolaunched flow, which is the supported way to add branching logic or call Apex through an invocable method. These are the only action types an Approval Process can attach directly. There is no option to run arbitrary Apex from an Approval Action, and there is no built-in way to call a REST service from one. When the logic you need goes past a simple field change or notification, the flow action is the escape hatch. It lets the process hand off to Flow, where you can read related records, branch on conditions, and call Apex. That single bridge keeps the Approval Process configuration declarative while still reaching code when a requirement demands it.
The five trigger points, in order
Initial Submission Actions run the moment a user submits the record, before the first approver sees it. By default the record is locked here, so users other than approvers and admins cannot edit it during review. Approval Step Actions belong to a specific step, and each step carries its own approval action set and its own rejection action set. They fire as that step resolves, which makes them useful for status updates partway through a multi-step chain. Final Approval Actions run only when the record clears every step with no approvals left to collect. Final Rejection Actions run when any approver rejects, which ends the process. Recall Actions run when the submitter pulls the request back before it finishes. A common arrangement locks the record on Initial Submission, updates a status field, and unlocks plus stamps a date on Final Approval or Final Rejection. Knowing exactly which trigger fires when keeps you from putting an action where it never runs, a frequent cause of confusing "why did nothing happen" tickets.
Record locking, the action you do not write
Locking is the behavior most admins associate with Approval Actions, and Salesforce handles it for you. When a record enters an approval process it is locked by default, which stops everyone except the current approvers and administrators from editing it. The lock protects the data an approver is reviewing, so a field cannot quietly change underneath the decision. You control who can still edit through the record editability setting on the process. The two choices are administrators only, or administrators and the currently assigned approver. There is a detail worth remembering: editability changes apply to records submitted after you save them. Records already in flight keep the setting they were submitted under, so to apply a new rule you recall and resubmit. On the resolution side, you decide whether the record unlocks or stays locked after final approval or rejection. Most teams unlock on both outcomes so the record returns to normal editing. You do not build the lock with a field update; it is a property of the process, with a built-in unlock available at the final steps.
Field update actions and re-evaluation
The field update is the workhorse Approval Action. A status field moving from Draft to Pending on submission, then to Approved or Rejected at the end, is the canonical example. Field updates inside an approval process can also reach a parent record across a master-detail link, which is handy when the rollup of an outcome belongs on the parent. Each field update carries a re-evaluate workflow rules setting. When it is on, updating the field can cause a workflow rule on that object to fire again, which lets a downstream rule react to the approval outcome. The capability is genuine, but it is off by default for a reason. If several actions all enable re-evaluation, and a downstream rule resubmits or re-triggers automation, you can build a loop that is painful to trace. Treat re-evaluation as a deliberate choice for one action, not a checkbox you tick everywhere. When the chain gets complicated, moving the logic into a flow action gives you clearer control and easier debugging than chaining workflow rules off approval field updates.
Email alerts without the spam
Email alerts are the second most common Approval Action. They send an email built from a template to recipients you select, which can include the record owner, the submitter, specific users, roles, public groups, or email fields on the record. The template can merge fields from the submitted record, so the message carries real context like the record name, amount, or reason. The two safe places for email alerts are Initial Submission, to confirm the request went out, and Final Approval or Final Rejection, to report the outcome. Per-step alerts are tempting because every milestone feels worth announcing. In practice they pile up fast, and once stakeholders learn the stream is noisy they stop reading all of it, including the messages that mattered. A useful rule is to email on submission and resolution by default, and add a per-step alert only when a named stakeholder genuinely needs that interim signal. Remember the approval process also sends its own assignment emails to approvers; your email alerts are in addition to those, so the total volume adds up quickly.
Outbound messages and the integration question
An outbound message action sends a SOAP message to an external endpoint you configure, carrying selected fields from the record. It was the original declarative way to tell an outside system that an approval reached a certain state, and existing ones keep working. For new integrations it is rarely the right tool. SOAP outbound messages are awkward to monitor, retry on a fixed schedule, and offer little visibility when the endpoint is down. The modern pattern is to use a flow action at the trigger point and let the flow do the integration work. From a flow you can make an HTTP callout to a REST service, publish a platform event for a loosely coupled subscriber, or write to an external object. Those approaches give you error handling, logging, and a clearer contract with the receiving system. If you inherit an approval process that fires outbound messages, it is usually safe to leave them running, but plan to replace them with flow-based integration when you next touch the design rather than adding more.
Flow actions and where logic should live
A flow action runs an autolaunched flow when its trigger point fires. This is how an Approval Process reaches past simple field changes and emails. A flow can read related records, branch on conditions the approval steps cannot express, loop over children, and call Apex through an invocable method. Because the flow receives the record context, you can drive complex post-decision logic from a single Final Approval or Final Rejection action. The broader trend in Salesforce automation is to keep Approval Actions thin and move real logic into Flow. An approval process that only locks the record, stamps a couple of status fields, and calls one flow at the end is easier to read and maintain than one stuffed with many field updates and per-step emails. It also centralizes the heavy logic in a tool with better debugging, fault paths, and testing. Use Approval Actions for the small, obvious side effects that belong to the decision itself, and let a flow handle anything with conditions, related data, or external calls.
How to add Approval Actions to an Approval Process
Approval Actions are not created on their own screen; you add them to an existing Approval Process at one of its five trigger points. The steps below add actions inside the Approval Process editor in Setup. You need an Approval Process already created on the object, and any email templates or flows you plan to reference should exist first.
- Open the Approval Process
In Setup, go to Process Automation and open Approval Processes, then choose the object and click into the process you want to edit. The detail page lists each trigger point as its own related list.
- Pick the trigger point
Find the section for the moment you want, such as Initial Submission Actions, Final Approval Actions, Final Rejection Actions, or Recall Actions. For a step-level action, edit the relevant Approval Step and use its approval or rejection actions.
- Add a new action
Click Add New on that section and choose the action type: Field Update, Email Alert, Task, Outbound Message, or Flow. You can also reuse an existing action instead of building a new one.
- Define the action
Fill in the specifics, such as the field and new value for a field update, or the template and recipients for an email alert. Save the action; it now runs whenever that trigger point fires.
- Set locking and editability
On the process itself, confirm record editability (admins only, or approver plus admins) and whether the record unlocks on final approval or rejection. Activate the process so the actions take effect.
Changes a field on the submitted record, or a parent across master-detail. Optionally re-evaluates workflow rules, which is off by default.
Sends an email from a template to chosen recipients. Best kept to submission and final resolution to avoid notification fatigue.
Creates an assigned Task record so a person has a tracked follow-up tied to the approval outcome.
Sends a SOAP message to an external endpoint. Legacy; prefer a flow with HTTP callout or platform events for new work.
Runs an autolaunched flow for branching logic, related-record updates, or Apex calls the other action types cannot do.
- Final Approval Actions run only when there are no remaining steps; if you expect them earlier, you have put them at the wrong trigger.
- Record editability changes apply only to records submitted after you save; recall and resubmit to apply a new setting to in-flight records.
- Enabling Re-evaluate Workflow Rules on many field updates can create loops between the approval process and workflow rules.
- Approval Actions cannot run Apex directly; wrap that logic in an autolaunched flow and call it with a Flow action.
Prefer this walkthrough as its own page? How to Approval Action in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Classic Approval Processes TerminologySalesforce
- Record Locking in Flow Approval ProcessesSalesforce
Straight from the source - Salesforce's reference material on Approval Action.
Hands-on resources to go deeper on Approval Action.
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. Which built-in Approval Action pair keeps a record stable while approvers review it?
Q2. What risk is introduced when a Field Update Approval Action has Re-evaluate Workflow Rules enabled?
Q3. Approval Actions cannot run arbitrary Apex directly. How do modern designs add conditional logic and Apex calls into the process?
Discussion
Loading discussion…