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.