Approval Request
An Approval Request in Salesforce is the record an approver acts on when a submitted record reaches a step in an approval process.
Definition
An Approval Request in Salesforce is the record an approver acts on when a submitted record reaches a step in an approval process. When a record is submitted and lands on a step, Salesforce creates the request and assigns it to the named approver (a user, a queue, or a public group). The approver finds it in the notifications tray, in the Items to Approve list on the home page, or in the email alert sent at submission. Approving, rejecting, or reassigning the request moves the underlying approval process to its next step or to its final outcome.
The Approval Request is the human-facing side of Salesforce's approval framework. The approval process is the configuration, the step is the logical checkpoint, and the request is what a person actually clicks. Each request shows the submitted record's key fields, the history of decisions so far, any comments left by earlier approvers, and the action buttons. For classic approval processes the data lives on the ProcessInstance, ProcessInstanceStep, and ProcessInstanceWorkitem objects, all queryable with SOQL for reporting and integration.
How an approval request moves a record forward
The lifecycle of one request
Follow a single request end to end. A sales rep submits a discount for approval, and the record enters the approval process. It reaches the first step, and Salesforce creates a ProcessInstanceWorkitem assigned to the rep's manager. The manager gets an email alert and also sees the item in the notifications bell. The manager opens the request, reads the discount amount and account name, types a short comment, and clicks Approve. That decision closes the workitem and writes a ProcessInstanceStep row recording who approved and when. The approval process then advances to step two, which might route the request to a finance queue for a second sign-off. Each hop creates a fresh workitem and, once acted on, a fresh step record. When the last step resolves, the process fires its final approval or final rejection actions, which can update fields, send alerts, or release the lock on the record. The request is short-lived by design. It exists while a decision is pending and converts into history the moment someone acts. That is why a stalled request is so visible: it is a workitem sitting in someone's queue with nobody acting on it.
Where approvers see pending requests
An approver does not have to hunt for work. The same pending request appears in three places at once, and acting in any one of them resolves it everywhere. The notifications bell in the top navigation shows a badge and a short list of items awaiting a decision. The Items to Approve component, which an admin can place on the Lightning home page, lists every workitem assigned to the logged-in user with inline Approve and Reject buttons. The email alert sent when the request was created carries the same record details and, when configured, reply-to links. Because all three read from the one ProcessInstanceWorkitem, there is no risk of approving twice. The first action wins, and the others simply show the item as already handled. The practical lesson for admins is to make sure the Items to Approve component is actually on the home page that approvers use. Many orgs leave approvers relying only on email, which works until someone has a full inbox and the request quietly ages past its deadline.
Approve, Reject, Reassign, and Recall
Four actions sit around a request, and they are not all available to the same person. Approve moves the record to the next step or to final approval. Reject ends the process with a rejection outcome and runs the final rejection actions. Reassign hands the open request to a different user, group, or queue, which is handy when the assigned approver is out and someone else needs to decide now. Reassignment touches only that one request; it does not change the approval process configuration, so the next submission still routes to the original approver. Recall, which Salesforce also calls withdraw, belongs to the submitter rather than the approver. It pulls the record back out of the process before anyone has decided. Recall is only available when the admin selected the option to allow submitters to recall requests, and even then only the submitter and a system administrator can do it. Knowing who holds which action saves a lot of confused support tickets. Approvers reassign, submitters recall, and nobody can do both without the right configuration in place.
Responding straight from email
Email Approval Response lets an approver act without opening Salesforce at all. Once an admin turns it on under Process Automation Settings, the approval alert includes instructions to reply. The approver replies to the email with APPROVE, APPROVED, or YES to approve, or REJECT, REJECTED, or NO to reject, placed on the first line of the message body. Salesforce parses the reply, confirms the sender's email matches a valid approver on the request, and applies the decision. Anything the approver types after that first line is captured as the approval comment, so a one-word answer plus a sentence of context both land correctly. The feature is strict about format. If the keyword is misspelled, or sits on the wrong line, or comes from an address that does not match the approver's user record, Salesforce ignores the reply and the request stays open. Delegated approvers can respond by email too. For a busy manager who approves from a phone all day, this single setting is often the difference between same-hour turnaround and a request that waits until they are back at a desk.
Delegation and coverage during absences
A request assigned to someone on vacation should not freeze the whole process. Salesforce handles this with the Delegated Approver field on the user record, set under Personal Information in a user's own settings or by an admin. While a delegate is named, that person receives the same incoming requests as the original approver and can act on them with full authority. Delegation is a standing arrangement, not a one-time handoff, which makes it the right tool for predictable coverage such as a manager who is always backed up by a deputy. It pairs naturally with reassignment: delegation covers planned absences set up in advance, while reassignment rescues a single request when nobody planned ahead. Many production orgs make delegated approver setup a condition of taking leave, precisely because one unwatched request can hold up a deal, an expense, or a contract for days. When a request does stall, the first thing to check is whether the assigned approver is out and whether a delegate was ever configured.
The objects behind the request
Classic approval data is stored across three standard objects, and reading them is how you build real reporting. ProcessInstance holds one row per submitted record per process run; it is the header for a single approval cycle. ProcessInstanceStep holds one row per step that has executed, recording the approver, the decision, the comment, and the timestamp. ProcessInstanceWorkitem holds one row per pending request, which means an open workitem is literally an undecided approval sitting in someone's queue. These rows are deleted automatically when the submitted record itself is deleted, so they track the live state of the record rather than a permanent log. Because all three are queryable with SOQL, you can build dashboards that Salesforce does not give you out of the box: average cycle time per approver, pending requests grouped by assignee, rejection rate by step. A custom report type that joins ProcessInstance to the submitted object exposes the business fields alongside the approval data, which is what turns raw workitem counts into something a manager will actually read.
Classic requests next to Flow Approval Processes
Approval Request as described here is the classic model, and it is still fully supported and widely used. Salesforce now also ships Flow Approval Processes, which became generally available in the Winter '25 release. They build approvals out of Flow Orchestration rather than the classic engine, so the pending unit of work is an approval work item linked to an orchestration work item rather than a ProcessInstanceWorkitem. Approvers complete those work items through the Orchestration Work Guide component, by email response, or from an Approval Work Items list view. The newer model adds flexibility classic lacks: richer routing logic, Apex extensibility, and detailed logging for audit. For unanimous group approvals it also withdraws the remaining pending child work items the moment any member rejects. Existing classic approval processes keep working, so there is no forced migration. When you read older docs, training, or an org built years ago, you will see the classic ProcessInstance objects; when you build something new and need conditional branching, the Flow-based path is the one Salesforce is investing in.
Enable Email Approval Response for approvers
Approval Requests are created automatically when a record is submitted, so there is nothing to build by hand. What an admin configures is how approvers act on them. The single highest-impact setting is Email Approval Response, which lets approvers reply to the alert instead of logging in. Here is how to turn it on for classic approval processes.
- Open Process Automation Settings
In Setup, type Process Automation Settings in Quick Find and open it. This page controls org-wide behavior for approvals and other automation.
- Enable email approval response
Select Enable Email Approval Response and save. Approval alerts will now include reply instructions for approvers.
- Check the approval email template
Confirm your approval process uses an email template (or the default) that explains how to reply. The default template already includes the APPROVE and REJECT instructions.
- Verify approver email addresses
Make sure each approver's User record has the email address they actually reply from. The parser matches the sender against the user, and a mismatch is silently ignored.
- Test with a real submission
Submit a sample record, reply to the alert with APPROVE on the first line, and confirm the request resolves and the comment is captured.
Org-wide switch that lets approvers reply to act. Off by default; one checkbox under Process Automation Settings.
APPROVE, APPROVED, or YES to approve; REJECT, REJECTED, or NO to reject, on the first line of the reply.
Per-process option that lets the original submitter (and an admin) withdraw a pending request before any decision.
User-record field that routes a copy of every incoming request to a named backup during absences.
- The reply keyword must sit on the very first line of the email body; a misspelling or a wrong line means Salesforce ignores the response and the request stays open.
- Email responses only work when the sending address matches the approver's User email, so forwarded or alias addresses can fail silently.
- Reassigning a request fixes only that one workitem; if the same wrong person keeps getting requests, change the approval process step instead.
- ProcessInstanceWorkitem rows are deleted with the submitted record, so build reporting around them as live state, not a permanent audit trail.
Prefer this walkthrough as its own page? How to Approval Request in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Approval Request.
- Classic Approval ProcessesSalesforce
- Approval Work Items and Orchestration Work ItemsSalesforce
Hands-on resources to go deeper on Approval Request.
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. Across which standard objects is Approval Request data stored as a record moves through a process?
Q2. Why do teams include decision-critical fields directly in the Approval Request email template?
Q3. What actions can an approver take when an Approval Request arrives for them?
Discussion
Loading discussion…