7.2 Approval Actions, Rejections & Record Locking
Key Takeaways
Approval processes execute automated actions across four distinct stages: Initial Submission, Step-Level (Approval/Rejection), Final Approval/Rejection, and Recall.
The only four automated actions natively supported within Approval Processes are Field Updates, Email Alerts, Tasks, and Outbound Messages.
Classic approval processes cannot use cross-object field update actions. Update a status on the submitted record and use an appropriate Flow for related-record changes, or use a Flow Approval background step.
During an active approval process, the record is locked against edits; only System Administrators and (optionally) the currently assigned Approver can edit locked records.
Enabling 'Re-evaluate Workflow Rules after Field Update' can cause subsequent declarative rules to evaluate, but risks triggering recursive loops if not carefully managed.
Approval Actions, Rejections & Record Locking
When a record transitions through an approval lifecycle, the platform executes automated responses that enforce data integrity, maintain audit compliance, and notify stakeholders of status changes. These responses are known as Approval Actions.
In addition to triggering automated actions, the platform automatically manages data governance by imposing Record Locking. While a record undergoes review, standard users must be prevented from altering deal amounts, discount terms, or delivery dates that would invalidate the approver's evaluation. Understanding the precise timing of approval actions, the scope of field updates, and the nuances of record locking is essential for building robust enterprise workflows and passing the Platform App Builder certification.
Approval Action Stages & Execution Timing
Salesforce Approval Processes organize automated actions into the following operational stages based on where the record sits within the approval lifecycle:
APPROVAL ACTION STAGES
│
┌─────────────────┬──────────────┴──────────────┬─────────────────┐
▼ ▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│Initial Submiss│ │ Step-Level │ │Final Approval/│ │ Recall Actions│
│ Actions │ │ Actions │ │ Rejection │ │ (Withdrawn) │
├───────────────┤ ├───────────────┤ ├───────────────┤ ├───────────────┤
│• Lock Record │ │• Step Approval│ │• Final Approv.│ │• Unlock Record│
│• Status Update│ │ (Advances or │ │ (Unlock/Lock,│ │• Reset Status │
│• Submitter Ack│ │ concludes) │ │ Commit DML) │ │• Notify Rep │
│• Outbound Msg │ │• Step Reject │ │• Final Reject.│ │• Cancel Tasks │
│ │ │ (Branch/fail)│ │ (Unlock, Log)│ │ │
└───────────────┘ └───────────────┘ └───────────────┘ └───────────────┘
1. Initial Submission Actions
Execute immediately after a record satisfies the process entry criteria and enters the approval pipeline.
- Standard Actions: The record is automatically locked by default. Administrators typically configure an initial field update setting
Approval_Status__cto'In Review'or'Pending Approval', alongside an automated email alert acknowledging receipt of the submission.
2. Step-Level Approval & Rejection Actions
Execute at the boundary of an individual approval step:
- Step Approval Actions: Fire when the assigned approver approves that specific step. If additional steps remain, the record advances to the next step; if this is the final step, the process transitions to Final Approval Actions.
- Step Rejection Actions: Fire when an approver rejects that specific step. Depending on step configuration, this either immediately invokes Final Rejection Actions or returns it to the previous approver, when that rejection behavior is available and configured.
3. Final Approval Actions
Execute when the record has successfully received all necessary approvals across all required steps in the sequence.
- Standard Actions: The administrator typically updates the record's primary status (e.g., setting
Statusto'Approved','Active', or'Closed Won'), unlocks the record (or leaves it locked against future modifications), dispatches confirmation emails to stakeholders, and optionally triggers an outbound message to an external ERP system for fulfillment.
4. Final Rejection Actions
Execute if an approver rejects the record and the process does not route to an alternate step.
- Standard Actions: The platform executes final rejection actions, commonly updating
Approval_Status__cto'Rejected', unlocking the record so the submitter can revise terms, and emailing the submitter with instructions or logged rejection comments.
5. Recall Actions
Execute when a submitted record is withdrawn prior to final approval.
- Triggering Recall: A recall occurs when the original submitter or a System Administrator clicks the Recall Approval Request button on the record.
- Standard Actions: Recall actions typically unlock the record, reset the status back to
'Draft', and withdraw pending approval work; separately created Task records need explicit cleanup.
Supported Automated Action Types
Classic approvals support four principal automated action types, with availability governed by the selected action stage; locking and unlocking are additional approval controls:
- Field Updates: Changes the value of a standard or custom field on the submitted record ; cross-object field updates cannot be assigned as classic approval actions. For picklist fields, administrators can select specific picklist values. For text, number, date, or currency fields, values can be set statically or computed via formula expressions.
- Email Alerts: Dispatches an email using a predefined Classic or Lightning Email Template to designated recipients, including users, roles, record owners, submitters, or related contact lookups.
- Tasks: Creates a new follow-up
Taskassigned to a designated user, role, or record owner. Useful for scheduling post-approval onboarding or fulfillment check-ins. - Outbound Messages: Sends a secure, configurable SOAP XML message payload containing specified record field values to an external listening endpoint (such as an enterprise middleware or billing system) without requiring Apex code.
Important
Unsupported Direct Actions: Approval Processes do not natively support posting to Chatter, invoking Screen Flows, launching autolaunched flows directly, or executing custom Quick Actions as direct approval actions. If a Chatter notification or complex multi-system transaction must occur upon approval, administrators must trigger an After-Save Record-Triggered Flow or Apex trigger that monitors the status field updated by the approval action.
Related-Record Updates and Workflow Re-evaluation
A classic approval field update targets the submitted record. Classic approval processes cannot use cross-object field update actions, including custom-to-custom master-detail relationships. Do not infer approval support from the similarly named legacy workflow feature.
To update a parent after a child is approved, set an approval-status field on the child and use an after-save Flow that reacts to the transition; supported modern Flow API versions run record-triggered flows for approval field updates. Alternatively, a Flow Approval process can run an autolaunched flow as a background step. When calculating a total across approved detail records, a filtered native roll-up may be simpler than incrementing a stored parent total. Account for rejection, resubmission, deletion, and concurrent approvals so the total cannot drift.
The legacy Re-evaluate Workflow Rules after Field Update option can cause up to five further reevaluations after the initial field update. It does not permit a classic approval to perform cross-object updates: cross-object actions reached through reevaluated workflow are ignored. Workflow Rules and Process Builder reached end of support on December 31, 2025; build new orchestration with Flow and test any remaining legacy interactions.
Record Locking Mechanics & Access Governance
When a record enters an active approval process, the platform enforces data immutability by placing the record in a Locked state. The record lock prevents simultaneous edits that could undermine the integrity of the pending approval.
Who Can Edit Locked Records?
During Step 3 of the Standard Setup Wizard, the app builder configures the Record Editability property. Salesforce provides exactly two options:
- Only Administrators can edit records during the approval process: Only users possessing the 'Modify All Data' system permission or 'Modify All' object-level permission for that sObject can edit the record while locked.
- Administrators OR the currently assigned approver can edit records during the approval process: In addition to System Administrators, the specific user or queue member currently holding the pending approval request can edit record fields before rendering a decision.
Note
Even when 'Administrators or currently assigned approver' is enabled, the submitting user cannot edit the record once locked. If the submitter realizes they entered an incorrect quantity or discount percentage, they must either ask the approver to make the correction, wait for a rejection, or use the Recall Approval Request action to unlock the record, apply edits, and resubmit.
Approval Action Stage Comparison Matrix
| Action Stage | Execution Trigger | Default Record State | Permitted Actions | Primary Use Case |
|---|---|---|---|---|
| Initial Submission | Record passes entry criteria upon submit | Locked | Field Update, Email Alert, Task, Outbound Msg | Set status to 'In Review', lock record, send submitter confirmation |
| Step Approval | Approver approves an intermediate step | Locked | Field Update, Email Alert, Task, Outbound Msg | Increment step audit field, notify next tier approver |
| Step Rejection | Approver rejects an intermediate step | Locked (or transitions) | Field Update, Email Alert, Task, Outbound Msg | Branch to secondary review, log rejection rationale |
| Final Approval | All approval steps completed successfully | Unlocked (or Locked) | Field Update, Email Alert, Task, Outbound Msg | Set status to 'Approved', unlock record, trigger ERP integration |
| Final Rejection | Request rejected without further steps | Unlocked | Field Update, Email Alert, Task, Outbound Msg | Set status to 'Rejected', unlock record for rep revisions |
| Recall Actions | Submitter or admin withdraws request | Unlocked | Field Update, Email Alert, Task, Outbound Msg | Reset status to 'Draft', unlock record, cancel pending review |
Best Practices & Common Exam Traps
Tip
Validation Rule Bypass Considerations: Approval field updates do not check custom validation rules. Standard field requirements can still cause errors, and downstream Flow/Apex can introduce additional save operations. Test approval transitions and do not rely on a custom validation rule alone to block an invalid approval-action value.
Important
Submitter Recall Permissions: By default, submitted records cannot be recalled by the submitter unless the administrator explicitly checks 'Allow submitters to recall approval requests' in the Approval Process Settings. If left unchecked, only an administrator can recall a pending request.
Common Exam Traps
- Trap 1: Attempting cross-object field updates across Lookup relationships. Classic approvals cannot use cross-object field update actions. Use Flow or a filtered master-detail roll-up when related records must change.
- Trap 2: Assuming sales reps can edit records while in approval. A common exam scenario involves a sales rep needing to update an Opportunity closing date while the Opportunity is in an active approval process. Even if the rep is the record owner, they cannot edit the record while locked. The rep must recall the approval request, make the modification, and resubmit.
- Trap 3: Believing Chatter posts can be added directly as approval actions. Chatter posts are not available as native approval actions. Only Field Updates, Email Alerts, Tasks, and Outbound Messages can be created directly within the approval action builder.
Official Source Check
Checked October 19, 2026: Classic approval field update restrictions.
A submitter notices an error in a locked pending approval. The process permits submitter recall and its recall action unlocks the record. The submitter is not an administrator or approver. Which option lets the submitter revise and resubmit without waiting for a decision?
Request that the System Administrator temporarily deactivate the approval process so the field can be modified
Contact Salesforce Customer Support to lift the record lock and have them disable approval record locking organization-wide from the Support console dashboard
Instruct the Finance Director to reject the approval request so the record reverts to an inactive state
Click the Recall Approval Request button on the record, update the timeline field on the unlocked record, and resubmit
Budget_Line_Item__c is a detail of Project_Budget__c. On final approval, its status must become Approved and related parent data must be updated. Which supported design should the builder choose?
Update approval status on the submitted child, then use an after-save Flow or a Flow Approval background step for the parent operation.
Use a classic cross-object approval field update to change the parent directly.
Insert SOQL directly into the classic step approval action.
Use a classic approval field update to modify any unrelated record.
Which combination of automated actions can an app builder configure natively within an Approval Process across its Initial Submission, Step, Final Approval, and Recall stages?
Field Updates, Screen Flow Invocations, Chatter Posts, and Email Alerts
Apex Invocations, Quick Actions, Tasks, and Outbound Messages
Field Updates, Email Alerts, Tasks, and Outbound Messages
Email Alerts, Platform Event Publications, Tasks, and Subflow Triggers
Sections you finish are checked off in the contents.