Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryAApproval Steps
AutomationAdvanced

Approval Steps

Approval Steps are the intermediate stages of a Salesforce Approval Process, each representing one decision point with its own filter criteria, assigned approvers, and behavior on approval or rejection.

§ 01

Definition

Approval Steps are the intermediate stages of a Salesforce Approval Process, each representing one decision point with its own filter criteria, assigned approvers, and behavior on approval or rejection. A simple Approval Process has one step (a manager approves an expense). A complex one chains many steps in sequence (finance approves first, then legal, then the CFO for amounts above a threshold). Each step decides whether the record advances to the next step, terminates the process (final approval or final rejection), or skips to a later step based on conditions. Steps are how the platform models hierarchical, conditional, and multi-stakeholder approvals.

An Approval Step is configured inside the Approval Process editor and stores its details on the ApprovalStep metadata. Each step has a Name, a Step Number, optional Step Criteria that filter which records hit this step, an Assigned Approver (a user, a manager-of-the-submitter, a queue, or a public group), a behavior on rejection (Final Rejection, or back to the prior step), an approval-step rejection action set, and an option to require unanimous approval if multiple approvers are assigned in parallel. The configuration is enough to model most real-world approval chains without writing code, with the Step Criteria providing the conditional logic that branches a single Approval Process across multiple paths.

§ 02

How Approval Steps model real-world decision chains

The anatomy of a single step

Each step carries a step number, a name, a step filter (the condition under which this step applies), an assigned approver, a rejection behavior, and optional per-step actions for both approval and rejection. The combination of step filter and approver is what makes one Approval Process serve multiple business scenarios without duplicating the process.

Sequential versus parallel steps

Steps execute in order. Each step finishes (approve or reject) before the next begins. To approve in parallel (multiple stakeholders on the same step), assign multiple approvers within one step and choose Require Unanimous Approval. The next step does not start until everyone on the current step has decided.

Step Criteria and conditional branching

Step Criteria lets one Approval Process model conditional paths. Step 2 might only apply when Amount > 10000. Records with Amount < 10000 skip Step 2 and move to Step 3. Step Criteria is a filter, not a true branch; the path that does not match a step's criteria simply skips that step.

Assigned Approver options

An approver can be a specific named User, the submitter's Manager (using the submitter's User.ManagerId field), a Queue, a Public Group, or the value of a User lookup field on the record (e.g., Account Owner). Manager-based assignment is the most common pattern in hierarchical approvals; queue-based is the common pattern for shared review pools.

Behavior on rejection

Each step decides what happens when an approver rejects. Final Rejection terminates the whole process with Final Rejection Actions firing. Back to the Previous Step returns the record to the prior step for re-decision. Modeling rejection behavior carefully is what makes processes recoverable; defaulting everything to Final Rejection forces re-submission for every single course-correction.

Step actions versus process-wide actions

Each step can fire its own approval and rejection actions, independent of the Initial Submission and Final Approval actions on the parent process. Per-step actions are useful for notifying mid-process stakeholders (post to Chatter when finance approves, send an email when legal rejects). Process-wide actions handle submission and final outcomes.

Reordering and removing steps

Step numbers can be reordered through the Approval Process editor. Salesforce renumbers automatically. Removing a step affects only future submissions; in-flight records continue on their original step path. This matters when iterating on a live process: changes do not retroactively shift records that are already mid-approval.

Common Approval Step patterns

Three patterns recur. The threshold pattern (each step's criteria filters by amount or risk band, so small items skip senior approvers). The hierarchical pattern (each step uses Manager-of-Submitter to walk up the org chart). The cross-functional pattern (steps alternate between sales, finance, and legal queues for parallel domain review). Most production processes mix two or three of these.

§ 03

How to configure Approval Steps

Step design is most of the Approval Process design effort. Approvers, conditions, and rejection behavior decide whether the process is humane and recoverable or rigid and frustrating.

  1. Open the Approval Process

    Setup, Approval Processes. Select the object, then open the Approval Process. Approval Steps are a related list on the process's detail page.

  2. Add a new step

    Click New Approval Step. Provide a Name, Step Number, and Description. Step numbers control execution order; reorder later if needed.

  3. Configure step filter criteria

    Decide whether the step applies to all records or only ones matching specific criteria (e.g., Amount > 10000). Records that do not match skip the step.

  4. Assign the approver

    Choose a specific user, the submitter's manager, a queue, a public group, or a lookup field. For parallel approvers within one step, add multiple and decide unanimous or any-one approval.

  5. Set rejection behavior and add step actions

    Pick Final Rejection or Back to Previous Step. Attach any approval or rejection actions specific to this step (email alerts, field updates, Chatter posts).

Gotchas
  • Records that do not match a step's criteria skip the step rather than reject. This is a common misunderstanding; if rejection on mismatch is needed, design the criteria as the inverse.
  • Parallel approvers within one step need an explicit Unanimous or Any decision rule. The default behavior differs by Salesforce version; set it explicitly.
  • Changes to steps do not retroactively affect in-flight records. They continue on the path the process had when they were submitted.
  • Manager-based approvers fail if the submitter has no Manager set on their User record. Validate Manager fields are populated before launching such processes.
§

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Approval Steps.

Keep learning

Hands-on resources to go deeper on Approval Steps.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

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?

Q2. What does step entry criteria allow you to do?

Q3. What does a unanimous approval step require?

§

Discussion

Loading…

Loading discussion…