Approval Steps
An Approval Step is one decision point inside a Salesforce Approval Process.
Definition
An Approval Step is one decision point inside a Salesforce Approval Process. Each step has its own entry criteria, an assigned approver or set of approvers, a behavior on rejection, and optional actions that fire when the step is approved or rejected. One step models a single sign-off, such as a manager approving an expense. Several steps chained in sequence model a longer review, such as finance approving first, then legal, then a senior leader for high-value records.
A step is configured in the Approval Process editor under the Approval Steps related list, and it is stored on the ApprovalStep portion of the ApprovalProcess metadata. Every step has a name, a step number that sets its order, optional step criteria that decide which records enter it, an approver assignment, and a rule for what happens if the approver rejects. Step criteria give one process conditional paths, so a small request and a large request can follow different routes without building separate processes. Steps are how Salesforce models hierarchical, conditional, and multi-stakeholder approvals declaratively, without code.
How approval steps are built and how they run
The parts of a single step
Every approval step is defined by a small set of properties that together describe one decision. The step number fixes where it sits in the running order. The name and an optional description label it for admins. Step criteria decide whether a given record enters this step at all, using either a filter (field-by-field conditions) or a formula that returns true or false. The assigned approver names who must respond. The rejection behavior says what happens if that approver says no. Optional approval and rejection actions attach side effects to the step itself. The pairing of step criteria and approver is what lets one process serve many situations. A record that does not match a step's criteria skips that step and moves on. A record that does match stops there until the assigned approver responds. Because each step is self-contained, you can read an approval process top to bottom and see exactly who signs off, in what order, and under what conditions. That readability is a big reason approval steps remain a common choice for sign-off logic even with newer automation available.
Sequential steps versus parallel approvers
Steps always run in order. Step 1 must finish, approved or rejected, before Step 2 begins. This is how you build a chain where each level depends on the one before it. A manager approves, then their director, then a vice president, each as a separate step. The record advances only when the current step is resolved. Parallel approval is a different idea and lives inside a single step, not across steps. When you assign more than one approver to the same step, Salesforce asks how to combine their responses. The two choices are approve or reject based on the first response, or require unanimous approval from all selected approvers. Unanimous means the step is not approved until every assigned approver has approved, and one rejection ends the step according to its rejection behavior. First response means the step resolves the moment any single approver acts. Use a single step with multiple approvers when several people review the same thing at the same time, such as finance and legal both clearing a contract. Use separate steps when one review must happen before the next can start.
Step criteria and conditional routing
When you add a step, you choose whether all records enter it or only records that meet criteria. Picking "Enter this step if the following criteria are met" turns the step into a conditional gate. You can express the condition as a set of field filters or as a Boolean formula. A common pattern gates a step on amount, so Step 2 fires only when Amount is greater than 10000, and smaller records skip straight past it. Step criteria act as a filter, not a true branch. There is no if-then-else fork that sends matching records down one path and non-matching records down another path. Instead, every record walks the same ordered list of steps, and at each step it either qualifies and stops, or fails the criteria and continues. To control what happens to a record that does not meet a step's criteria, you set the "if records do not meet entry criteria" option to either approve the record (treat the step as satisfied and move on) or reject the record outright. Thinking of criteria as a series of gates, rather than as branches, keeps the design clear when a process has many steps.
Choosing the assigned approver
Salesforce gives several ways to name who approves a step. You can let the submitter choose the approver manually when they submit. You can automatically assign using a user field, most often the Manager field, which walks up the role or management hierarchy from the submitter. You can automatically assign to a specific named user, to a queue, or to the value of a related user lookup on the record, such as the Account Owner. You can also use a hierarchy field to climb a custom org-chart relationship. Manager-based assignment is the workhorse of hierarchical approvals, because it adapts automatically as people change managers. Queue-based assignment suits shared review pools, where any member of a team can pick up and act on the request. Specific-user assignment is fine for a single named gatekeeper but becomes fragile when that person leaves or goes on leave, so it pairs well with delegated approvers. When you assign more than one approver in a step, remember to set the unanimous or first-response routing rule, because that choice changes how the step resolves.
Behavior when an approver rejects
Each step decides what a rejection means. For the first step, rejection always ends the process as a final rejection, because there is nothing earlier to return to. For later steps you get a choice. "Perform all rejection actions" (final rejection) terminates the whole process, locks the outcome, and fires the process-level Final Rejection Actions. "Perform only this step's rejection actions and send the approval request back to the most recent approver" returns the record to the previous step so that approver can reconsider, rather than forcing a full resubmission. How you set this is what makes a process recoverable or painful. If every step defaults to final rejection, a single objection at the last stage throws the record all the way back to square one, and the submitter has to start the approval over. Sending it back one step instead lets an approver correct course and re-approve without unwinding everyone else's decisions. Map the rejection behavior deliberately for each step, because the default is rarely what a real review workflow wants.
Step actions, ordering, and edits to live processes
A step can carry its own approval actions and rejection actions, separate from the Initial Submission and Final Approval actions on the parent process. Per-step actions are how you notify mid-process stakeholders: post to Chatter when finance approves, send an email alert when legal rejects, or update a status field as the record moves through the chain. The allowed action types are the same declarative set used elsewhere, including field updates, email alerts, tasks, and outbound messages. Step numbers can be reordered in the editor, and Salesforce renumbers the remaining steps automatically. There is an important rule about editing a process that is already in use. To change steps on an active approval process, you typically deactivate it first, and changes you make affect only records submitted after the change. Records already in flight keep traveling their original step path. That isolation protects in-progress approvals from shifting underneath approvers, but it also means a fix you make today will not retroactively reroute a record that is already mid-approval.
How to add an approval step
Approval steps are added one at a time from inside an existing Approval Process. Build the process shell first, then add steps in the order approvers should act. Each step needs entry criteria, an approver, and a rejection rule before you activate.
- Open the Approval Steps related list
From Setup, open your Approval Process and find the Approval Steps related list. Click New Approval Step. Steps are created in sequence, so add them in the order you want approvers to act.
- Set the step name and entry criteria
Give the step a clear Name and Step Number. Choose "All records should enter this step" or "Enter this step if the following criteria are met," then define the filter or formula. Decide what happens to records that do not meet the criteria.
- Assign the approver
Pick how the approver is set: let the submitter choose, automatically assign using a user field like Manager, or assign to a specific user, queue, or related user. If you add more than one approver, choose first-response or require unanimous approval.
- Set the rejection behavior
For steps after the first, choose whether a rejection ends the process as a final rejection or sends the record back to the previous approver. Then add any step-level approval or rejection actions you need.
- Save, repeat, and activate
Save the step and repeat for each decision point in the chain. Review the full ordered list, then activate the approval process so new submissions follow the steps.
Filter or formula that decides which records enter this step; records that fail can be approved past it or rejected.
Who acts on the step: submitter choice, a user field such as Manager, a specific user, a queue, or a related user lookup.
When several approvers are on one step, choose approve/reject on the first response or require unanimous approval.
For later steps, choose final rejection (ends the process) or send the record back to the most recent approver.
Optional approval and rejection actions for the step, such as field updates, email alerts, tasks, and outbound messages.
- The first step can only end in final rejection on a no, because there is no earlier step to return to.
- Step criteria filter records into a step; they do not branch records down separate paths the way a flow decision does.
- Manager-based steps break silently when the submitter has no Manager value, so validate that field before activating.
- Editing steps on an active process affects only future submissions; in-flight records keep their original path.
Prefer this walkthrough as its own page? How to Approval Steps in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Approval Steps.
Hands-on resources to go deeper on Approval Steps.
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 is an Approval Step within a Salesforce Approval Process?
Q2. What does step entry criteria make possible across the steps of an Approval Process?
Q3. When multiple approvers are assigned to one step with Require Unanimous Approval, what must happen for that step to advance?
Discussion
Loading discussion…