Recall Actions
Recall Actions are the automated actions that run in a Salesforce approval process when a submitter withdraws a pending approval request before it finishes.
Definition
Recall Actions are the automated actions that run in a Salesforce approval process when a submitter withdraws a pending approval request before it finishes. They fire only when an in-progress request is recalled, and they typically reverse the changes that the initial submission made so the record returns to its pre-submission state.
You configure recall actions in the approval process itself, alongside initial submission actions, final approval actions, and final rejection actions. A recall is allowed only when the approval process has "Allow submitters to recall approval requests" turned on. Common recall actions reset a status field, send an email alert, or fire an outbound message.
How recall actions clean up after a withdrawn request
Where recall fits in the approval lifecycle
A classic approval process has several action slots that fire at different moments. Initial submission actions run the instant a record enters the process. Approval and rejection actions run as approvers respond at each step. Final approval and final rejection actions run when the whole process resolves. Recall actions sit apart from all of those. They fire only when a submitter pulls a still-pending request back out of the queue. A recall is different from a rejection. A rejection is a decision made by an approver. A recall is the submitter changing their mind before anyone decides. Maybe they spotted a mistake on the record, attached the wrong file, or no longer need sign-off at all. Because the request never reached a verdict, Salesforce gives you a dedicated place to undo whatever the submission set in motion. Without recall actions, a withdrawn record could sit in a half-submitted state, showing a "Pending" status with no active request behind it. That mismatch confuses reports and users alike, so the recall slot exists to put the record back the way it was.
Turning recall on for an approval process
Recall is not automatic. An approval process only lets submitters withdraw a request when the "Allow submitters to recall approval requests" checkbox is selected in the process configuration. With that box unchecked, the Recall Approval Request button never appears, and the recall action slot has nothing to trigger it. This is the single most common reason a carefully built recall action does nothing in production. When the option is on, a submitter (or anyone with access to the approval history) sees a Recall Approval Request button on the record's approval history related list. Clicking it withdraws the request, removes it from approvers' queues, and immediately runs whatever recall actions you defined. The setting is process-specific, so you decide per approval process whether withdrawal is allowed. For a low-stakes time-off request you might allow it freely. For a contract that triggers downstream billing, you might leave recall off so a submission cannot quietly disappear once it starts.
What recall actions can actually do
Recall actions support the same action types as the other slots in a classic approval process. The four you can add are a field update, an email alert, a task, and an outbound message. A field update is by far the most common choice. It writes a value back to a field on the record, which is how you flip a custom Approval Status field from "Submitted" or "Pending" back to "Recalled" or a blank state. Email alerts on recall notify the right people that a request was pulled, which matters when an approver was already mid-review or when a downstream team was waiting on the outcome. Tasks create follow-up work, for example reminding the submitter to fix the record and resubmit. Outbound messages send a SOAP message to an external endpoint, useful when an outside system was told that an approval started and now needs to hear that it stopped. You can stack several actions in one slot, so a single recall can reset a field, email a manager, and ping an integration all at once.
Reverting submission-time field updates
The cleanest reason to build recall actions is symmetry with your initial submission actions. A typical approval process sets a status field to "Pending Approval" the moment a record is submitted, often through an initial submission field update. That value tells everyone the record is locked in review. If a submitter then recalls, that "Pending Approval" value is now wrong, because no review is happening. A recall field update fixes this. You add a field update in the recall slot that sets the same status field back to "Draft", "Not Submitted", or "Recalled", whichever value your process uses for an open record. Salesforce does not undo submission field updates on its own, so this reset is your responsibility to configure. The pattern to remember is: whatever the initial submission action changed, the recall action should change back. Walk through every field the submission touched and decide what its recalled value should be. Miss one and you leave a stale value that makes the record look busier than it is.
Record locking and the recall reset
Submitting a record for approval usually locks it. By default, once a record enters an approval process, only administrators and the assigned approver can edit it, which stops anyone from quietly changing the data while it is under review. You control this with the record editability setting on the process. The lock is meant to protect the record during the decision window. Recall releases that lock automatically. When a submitter withdraws the request, Salesforce unlocks the record as part of ending the approval, so the submitter can edit it again, fix whatever prompted the recall, and resubmit. You do not configure unlocking as a recall action; it is built into the recall behavior itself. This is worth knowing because it explains a common support question. A user says they cannot edit a record, an admin recalls the pending request, and suddenly the record is editable again. The unlock came from the recall, not from any field update you added to the slot.
Recall in Flow-based approvals
The recall idea now extends beyond classic approval processes into the newer Flow-based approvals built with approval orchestrations. In a Flow approval process you can add a recall path, which is the orchestration equivalent of the classic recall action slot. The recall path runs when an approval submission is recalled, and inside it you place flow steps to perform the cleanup, much as field updates handled cleanup in the classic model. There is also a Recall Approval Submission action you can call from a flow or autolaunched process. It withdraws an approval submission that has not yet completed and lets you record a comment noting that the submitter or an approval admin made the recall. As with the classic version, the submission must permit recall for the action to work. If you are building new automation, the Flow approval recall path is the forward-looking option, while classic recall actions remain fully supported on the many approval processes already running across orgs today.
Configure recall actions on a classic approval process
Recall actions are configured inside an existing classic approval process from Setup. You add them after the process is created, in the Recall Actions related list on the process detail page.
- Allow recall on the process
Open the approval process in Setup. Edit its properties and select "Allow submitters to recall approval requests" so the Recall Approval Request button appears for users.
- Open the Recall Actions related list
On the approval process detail page, scroll to the Recall Actions related list. Click Add New and choose the action type you want, such as Field Update.
- Add a field update to reset status
Create a field update that sets your status field back to its open value, for example Approval Status to "Recalled". Match it to whatever your initial submission action set.
- Add notifications if needed
Add an email alert or task so approvers or the submitter are told the request was withdrawn. Stack multiple actions in the slot if one recall should do several things.
- Activate and test
Activate the process, submit a test record, then click Recall Approval Request. Confirm the status reset, the record unlocked, and any alerts fired.
Writes a value to a field on the recalled record. Most often used to set a status field back to a draft or recalled value.
Sends a templated email when the request is recalled, typically to notify approvers or the submitter that review has stopped.
Creates a follow-up task, for example reminding the submitter to correct the record before resubmitting.
Sends a SOAP message to an external endpoint so an integrated system learns the approval was withdrawn.
- If "Allow submitters to recall approval requests" is off, the recall button never shows and recall actions never run.
- Salesforce does not auto-revert initial submission field updates; you must add matching field updates in the recall slot.
- Recall unlocks the record automatically, so do not build a separate action just to make it editable again.
- Recall actions fire only for in-progress requests; a completed or rejected request cannot be recalled.
Prefer this walkthrough as its own page? How to Recall Actions in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Recall Actions.
Hands-on resources to go deeper on Recall 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 Recall Actions in a Salesforce approval process?
Q2. When do Recall Actions actually fire?
Q3. What kinds of steps are typical Recall Actions?
Discussion
Loading discussion…