Assigned Approver
An Assigned Approver in Salesforce is the user, queue, or related user named on an Approval Step to act on every approval request that reaches that step.
Definition
An Assigned Approver in Salesforce is the user, queue, or related user named on an Approval Step to act on every approval request that reaches that step. The approval process configuration sets the Assigned Approver at design time, and the platform resolves who that actually is at runtime, when a record flows through the step. Depending on the assignment type chosen, the approver can be the submitter's manager, a specific user, a queue, a public group, or the value of a hierarchical user field on the record.
Choosing the Assigned Approver is the central decision in an approval step. Get it right and the request lands with someone who has context and authority, so the decision happens fast. Get it wrong and requests stall, escalate to the wrong person, or sit unanswered. Salesforce assigns approvers per step, so one approval process can route the same record through different approvers at each stage, modeling multi-stakeholder sign-off without any code.
How Salesforce resolves who approves
Where the Assigned Approver is set
The Assigned Approver lives on an approval step, not on the approval process header. When you add a step, the wizard asks who should act on requests that reach it. Three top-level choices appear. "Let the submitter choose the approver manually" hands the pick to the person submitting the record. "Automatically assign using the user field selected earlier" follows a hierarchical user field, most often the standard Manager field. "Automatically assign to approver(s)" lets you name one or more specific approvers directly, choosing User, Queue, or a Related User from a dropdown for each one. Because the setting is per step, a single process can mix these. Step one might follow the submitter's manager, step two might target a finance queue, and step three might name a specific executive. That flexibility is why approval processes can mirror real organizational sign-off without custom Apex. The choice you make here is stored on the step and is what the platform reads every time a record reaches that point in the process.
Manager of the submitter
The most common pattern uses the submitter's manager. On the step you select a user field with "Next Automated Approver Determined By", and the standard Manager field is the usual choice. At runtime the platform reads Manager on the submitting user's record and routes the request there. This pattern survives reorganizations because it follows the live hierarchy rather than a hard-coded name. The catch is data quality. If a submitter's Manager field is blank, the step has no one to route to and the request fails at that point. There is also a subtle multi-step behavior worth knowing. If you select "Use Approver Field of Record Owner" so the first step uses the record owner's manager, every step after that refers to the manager of the previous approver, not the manager of the record owner. That chaining is intentional and produces a true management escalation, but it surprises admins who expect every step to look back at the original owner.
Queues and public groups
Assigning a queue sends the request to a shared inbox that any queue member can act on. The first member to approve or reject resolves it for everyone, which suits functional teams like legal, finance, or deal desk where no single person owns the decision. A public group works similarly when you name it as an approver, routing the same request to every member without a dedicated queue list view. Both patterns spread coverage so a single person being out of office does not block the pipeline. The trade is visibility. A request sitting in a queue belongs to no individual, so it can be ignored if nobody treats the queue as their responsibility. Inactive users who remain queue members add to the confusion, because they appear assigned but can never act. Teams that rely on queue approvals usually pair them with a clear ownership convention and a report on aging requests so nothing rots quietly in a shared inbox.
Related user fields on the record
Sometimes the right approver depends on the record, not on who submitted it. A related user field lets the record itself name the approver. You pick a hierarchical user lookup, and the platform reads that field on the record at runtime. Account Owner, a custom Region Director lookup, or a Deal Sponsor field can all act as the approver. A high-value named account might always route to its Account Owner no matter who keyed in the request. This keeps routing tied to accountability for the record rather than the accident of who started the process. The field must be a user lookup that resolves to an active user, and a blank value breaks the step the same way a missing manager does. Related user assignment shines when ownership is meaningful, such as territory-based deals or service contracts where one named person is responsible regardless of which rep or agent files the change.
Multiple approvers on a single step
One step can require more than one approver at the same time. When you assign several, Salesforce asks how their decisions combine. "Approve or reject based on the first response" resolves the step as soon as any one assigned approver acts, so the first decision wins. "Require unanimous approval from all selected approvers" holds the step open until every assigned approver approves, and a single rejection from any of them rejects the step. First-response steps move fast and suit any-one-of-several coverage. Unanimous steps enforce true cross-functional sign-off, the kind where legal, finance, and engineering each need to bless a change before it advances. Approvers on a unanimous step should know their vote is one of several, because the experience differs from being the sole decision maker. Naming the rule in the step name or description, such as "Risk Review (Unanimous)", saves approvers from guessing whether their click is final or just one piece of the outcome.
Delegation and per-request reassignment
Two mechanisms keep work moving when the Assigned Approver cannot act. Each user can set a Delegated Approver in their personal settings. While that is in place, the delegate receives the request alongside the original approver, and either one can decide. Delegation is the standard answer for planned absences, and disciplined orgs make people set it before they go on leave. Separately, an approver looking at a specific pending request can reassign just that request to someone else. This is a one-time move that does not change the step configuration. The next record that reaches the step still routes to the original Assigned Approver. The two tools solve different problems. Delegation is a standing rule the approver sets for themselves, while reassignment is an ad hoc handoff of a single live request. Permanent rerouting, by contrast, means editing the approval step itself, which only an admin with the right permission can do.
Pitfalls that strand approvals
A handful of failure modes recur often enough to plan around. Blank Manager fields are the top offender. A Manager-of-submitter step has nowhere to send a request when the submitter has no manager set, so requests fail silently for that population. Named-user assignment carries a different risk. When the named approver leaves the company, every request that targets them strands until an admin notices and edits the step. Inactive users sitting in approval queues hold requests invisibly, looking assigned while being unable to act. Related user fields fail the same way a blank manager does when the lookup is empty. None of these throw a loud error in day-to-day use, which is exactly why they linger. The defense is routine. Audit Assigned Approvers across every approval process on a regular cadence, verify Manager data before launching any manager-based step, and prefer roles and hierarchy over hard-coded names wherever the business rule allows it.
Set the Assigned Approver on an approval step
You set the Assigned Approver while adding or editing an approval step, in Setup under the approval process. Decide first whether the approver should be the submitter's manager, a named user or queue, or a person the record itself points to. Then pick the matching assignment option on the step.
- Open the approval process
In Setup, go to Approval Processes, choose the object, and open the process you want. Approval steps appear in the Approval Steps related list. Click New Approval Step to add one or edit an existing step.
- Reach the approver selection screen
Work through the step wizard past Step Name and the step criteria. The third screen, Select Assigned Approver, is where you choose who acts on requests that reach this step.
- Pick the assignment type
Choose one option. Let the submitter choose the approver manually, automatically assign using the user field selected earlier (such as Manager), or automatically assign to approver(s) and add specific Users, a Queue, or a Related User from the dropdown.
- Set the multi-approver rule
If you add more than one approver, choose how their decisions combine. Pick approve or reject based on the first response, or require unanimous approval from all selected approvers.
- Save and activate
Save the step, then activate the approval process. Submit a test record so you can confirm the request lands with the approver you expected before users rely on it.
The person submitting the record selects the approver at submission time. Flexible, but it depends on submitters knowing the correct approver.
Follows a hierarchical user field, usually Manager, read from the submitting user. Survives reorganizations but breaks if the field is blank.
Name one or more approvers directly. Each can be a specific User, a Queue, or a Related User field on the record.
Uses the record owner's user field instead of the submitter's. Note that later steps then chain off the previous approver's manager, not the owner.
- A blank Manager field on the submitter makes a manager-based step fail with no obvious error, so verify the data before going live.
- Once a step uses Use Approver Field of Record Owner, every following step refers to the manager of the previous approver, not the record owner.
- Inactive users left in approval queues look assigned but can never act, quietly holding requests until someone audits the queue.
- Naming a specific user as the approver strands requests when that person leaves; prefer manager, role, or queue assignment where you can.
Prefer this walkthrough as its own page? How to Assigned Approver in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Assigned Approver.
Hands-on resources to go deeper on Assigned Approver.
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. Which of these is a valid Assigned Approver assignment on an Approval Step?
Q2. What silently breaks a Manager-of-Submitter Assigned Approver step?
Q3. When an approver reassigns a single pending request, what happens to future submissions?
Discussion
Loading discussion…