Final Rejection Actions
A Final Rejection Action is an automated action that runs when a record is rejected in a Salesforce approval process and there is no path forward.
Definition
A Final Rejection Action is an automated action that runs when a record is rejected in a Salesforce approval process and there is no path forward. Once any required approver rejects the request, the process ends with a rejection outcome and the Final Rejection Actions fire at that moment. The configuration sits inside the approval process itself, so an admin defines exactly what happens the instant a request is turned down.
These actions are the rejection-side counterpart to Final Approval Actions. An admin can use them to set an approval status field to Rejected, send an email alert to the submitter, create a follow-up task, send an outbound message to an external system, or change whether the record stays locked. They give a rejected request a clear ending and, in most orgs, set up the next revise-and-resubmit cycle.
How Final Rejection Actions close out a rejected request
The exact moment they fire
Final Rejection Actions run when a record reaches a final rejection state. That happens when an approver rejects and the process has nowhere else to send the request. In a single-step approval, one rejection ends everything, so the Final Rejection Actions fire right away. In a multi-step approval, the outcome depends on the rejection behavior set on each step. A step can be configured to perform all rejection actions and end the whole process, or to perform only that step's rejection actions and send the request back to the previous approver. The first option triggers Final Rejection Actions. The second keeps the request alive and does not. This is the difference that trips people up. A three-step approval rejected at step two does not always end the process. It ends only if that step is set to reject the entire request. Because of this, an admin needs to think about per-step rejection behavior and the final outcome together. The Final Rejection Actions describe what a fully rejected request looks like, not what every individual rejection does.
The four action types you can add
Final Rejection Actions reuse the same automated action types available elsewhere in the approval process. You can add a field update, an email alert, a task, or an outbound message. A field update changes a value on the record, most often setting an approval status picklist to a rejection value or clearing fields that no longer apply. An email alert sends a templated message to chosen recipients, usually the submitter and sometimes their manager. A task creates a follow-up activity assigned to a user, which gives the rejection a concrete next step. An outbound message sends record data as a SOAP call to an external endpoint, useful when another system tracks the same request. The action types are identical to those in Final Approval and Initial Submission Actions. Only the trigger moment and the values you choose differ. That means a rejection field update should set rejection-specific values, and a rejection email should use a template written for a turned-down request, not a generic approval notice.
Record locking on rejection
Salesforce locks a record when it enters an approval process so that only approvers and admins can edit it while a decision is pending. When the process ends, the record needs a defined lock state, and Final Rejection Actions include a Record Lock setting for exactly that. An admin chooses whether the rejected record stays locked or unlocks for editing. The choice matters because it shapes the next step. If the team expects the submitter to fix the request and resubmit, unlocking lets them edit straight away. If a rejected request should stay frozen for review or audit, keeping it locked enforces that. The Record Lock setting appears in the Final Rejection Actions section next to the automated actions, and it is easy to overlook. Treat it as a deliberate decision rather than an afterthought. A rejected record that stays locked when the submitter needs to edit it creates a support ticket. A record that unlocks when policy says it should stay frozen creates a compliance gap.
Carrying the rejection reason forward
An approver can enter a comment when they reject a request, and that comment is the single most useful piece of context the submitter gets. Final Rejection Actions are where you make sure it travels. The most common pattern is an email alert whose template embeds the approval comment as a merge field, so the submitter reads why the request was turned down rather than a bare notification. Without that reasoning, the submitter is left guessing and the next submission often repeats the same mistake. A field update can also stamp a date or a status that records when the rejection happened. For a worked example, picture a discount request on an opportunity. The sales manager rejects it with the comment that the margin is too thin. The Final Rejection Actions set Approval Status to Not Approved, clear the requested discount percentage, and email the opportunity owner using a Discount Rejected template that includes the manager's comment. The owner now knows the request failed, knows why, and has a clean record to revise.
Step rejection actions versus final rejection actions
Two layers of rejection handling exist in an approval process, and keeping them straight avoids surprises. Step-level rejection actions, called Rejection Actions on an individual step, run when that specific step is rejected. Final Rejection Actions run only when the whole process ends in rejection. They are not the same thing, although a step set to reject the entire request will trigger both its own step actions and the Final Rejection Actions. Use step rejection actions when you want each rejecting approver to fire something specific to their level, such as a note to that approver's manager. Use Final Rejection Actions for the outcome that applies no matter which step said no, such as setting the master status field and notifying the submitter. A common mistake is loading everything into one layer. If you put submitter notification only on a step that can send the request back, the submitter never hears about a true final rejection. Mapping each action to the layer that fits its purpose keeps the automation predictable.
Where Final Rejection Actions fit today
Approval processes remain a supported and widely used part of the Salesforce platform, and Final Rejection Actions are configured directly in the approval process builder under Setup. Newer orgs may also build approval logic in Flow, which has its own approval orchestration and recall paths, but classic approval processes and their final action sections are still fully active. The action types carry one note about modernization. Outbound messages predate platform events and still work, yet many teams now prefer publishing a platform event on rejection so subscribers react asynchronously and the integration stays loosely coupled. For a brand new integration, a platform event is usually the cleaner choice. For an existing outbound message wired into a working system, there is no urgency to rip it out. The broader point is that Final Rejection Actions are a stable, declarative way to give a rejected request a defined ending. They cover status, notification, follow-up, locking, and integration in one place, which keeps rejection handling visible to anyone who opens the approval process later.
Configure Final Rejection Actions on an approval process
Final Rejection Actions are configured inside an existing approval process in Setup. You add automated actions to the Final Rejection Actions section and set how the rejected record should be locked. The approval process must be deactivated before you can edit its actions, then reactivated when you are done.
- Open the approval process
In Setup, go to Process Automation and open Approval Processes. Pick the object, then click into the approval process you want to change. Deactivate it first, because Salesforce blocks edits to actions while a process is active.
- Find the Final Rejection Actions section
Scroll to the Final Rejection Actions section near the bottom of the detail page. This is separate from the per-step Rejection Actions and from the Final Approval Actions section, so confirm you are in the right one.
- Add the automated actions
Click Add New and choose Field Update, Email Alert, Task, or Outbound Message. Create a field update to set your approval status field to a rejection value, and add an email alert using a template written for rejections. Repeat for each action the outcome needs.
- Set the record lock behavior
Use the Record Lock option in the section to decide whether the rejected record stays locked or unlocks for editing. Choose unlock if the submitter should revise and resubmit, or keep it locked if the record should freeze for review.
- Reactivate and test
Activate the approval process again. Submit a test record, reject it, and confirm the field updates apply, the email arrives with the rejection comment, and the lock state matches what you chose.
Changes a value on the rejected record, commonly setting an approval status picklist to Rejected or clearing fields tied to the request.
Sends a templated email to chosen recipients, typically the submitter, ideally with the approver's rejection comment merged in.
Creates a follow-up activity assigned to a user so the rejection has a concrete next action, such as review and revise.
Sends record data as a SOAP message to an external endpoint when another system needs to know the request was rejected.
Sets whether the rejected record stays locked or unlocks for editing once the process ends in rejection.
- You cannot edit Final Rejection Actions while the approval process is active. Deactivate it first, make changes, then reactivate.
- Final Rejection Actions fire only on a true final rejection. A step set to send the request back to the previous approver does not trigger them.
- The Record Lock setting is easy to miss. Decide it on purpose, because the wrong lock state either blocks resubmission or leaves a record editable when it should be frozen.
- A rejection email with no merge field for the approver's comment leaves the submitter guessing about why the request failed.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Final Rejection Actions.
Hands-on resources to go deeper on Final Rejection 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. When do Final Rejection Actions fire?
Q2. What types of actions can Final Rejection Actions include?
Q3. Why is it important to configure Final Rejection Actions?
Discussion
Loading discussion…