Study guide
7.1 Multi-Step Approval Processes & Approver Routing
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
7.1 Multi-Step Approval Processes & Approver Routing
Key Takeaways Explain This Topic AI
Approval processes enforce sequential or conditional business signoffs, locking records and routing them to users, queues, manager hierarchies, or custom hierarchical lookup fields.
Parallel approvals support up to 25 approvers per step, configured either for unanimous consensus (all must approve) or first-response determination (the first action decides the outcome).
A Delegated Approver designated on a user's record can approve or reject assigned requests, but lacks the administrative authority to reassign requests to other users.
Queues can act as approvers only for custom objects and supported standard objects (such as Cases and Leads); Opportunities and Accounts do not support queue-based approvers.
Active approval processes cannot have steps added, deleted, or reordered; structural modifications require cloning the process to create a new version.
Last updated: October 2026
Multi-Step Approval Processes & Approver Routing
In enterprise CRM implementations, business governance frequently demands formal authorization before records transition through critical lifecycle stages. A sales representative cannot unilaterally grant a 40% discount on an enterprise deal, an HR coordinator cannot finalize an executive compensation plan without department head signoff, and a procurement specialist cannot issue purchase orders exceeding $50,000 without multi-tier executive approval. On the Salesforce platform, Approval Processes provide the declarative framework for automating these formal, auditable signoff sequences.
Note
Classic approvals now have a Flow-native sibling. Since Spring '25, approvals can also be built as Flow approval processes (approval orchestration) directly in Flow Builder, expanded in Summer '25 and Winter '26. The classic approval processes this chapter covers remain fully supported and still win for simple linear routing; Section 12.4 builds the Flow-native model, its step types, and the migration considerations.
While Salesforce Flow serves as the primary engine for autonomous, event-driven data manipulation, Approval Processes remain the dedicated platform mechanism for human-in-the-loop governance. They uniquely combine automated record locking, multi-tiered routing hierarchies, out-of-office delegation, and comprehensive audit tracking through the native Approval History related list.
Approval Process Architecture & Setup Wizards
An approval process automates how records are submitted, evaluated, approved, or rejected by designated users within an organization. When creating an approval process in Salesforce Setup, administrators choose between two configuration wizards:
Jump Start Wizard: A streamlined, single-screen configuration wizard designed for basic, single-step approval workflows. It automatically applies default platform settings for record editability and notification templates, requiring the app builder only to specify the process name, entry criteria, and a single approver definition.
Standard Setup Wizard: A comprehensive, six-step wizard required for complex, enterprise-grade approval workflows. The standard wizard systematically configures:
Step 1: Process Definition & Naming: Establishes the label, API name, and target sObject.
Step 2: Entry Criteria: Defines the baseline boolean criteria or formula filters a record must satisfy to enter the approval pipeline.
Step 3: Approver Field & Record Editability: Designates whether standard manager hierarchies or custom hierarchical fields govern routing, and determines whether only System Administrators or both Administrators and the currently assigned Approver can edit records during the approval cycle.
Step 4: Notification Templates: Selects the outbound email templates dispatched to approvers upon submission and step transitions.
Step 5: Approval Page Layout & History: Selects the display fields rendered on the approval decision screen and controls whether approval history is displayed.
Step 6: Initial Submitters: Defines which users, roles, public groups, or record owners have permission to manually click the Submit for Approval button.
Entry Criteria vs. Step Criteria
A critical architectural distinction exists between Process Entry Criteria and Step Criteria :
Process Entry Criteria: Evaluated exactly once at the moment a user or automated flow invokes submission. If the record satisfies the process entry criteria (e.g., Opportunity.Discount_Percentage__c > 0.15 ), the record enters the approval pipeline, executes Initial Submission Actions, locks against standard edits, and advances to Step 1. If the criteria evaluate to FALSE , the submission terminates immediately with an error informing the user that the record does not qualify for approval.
Step Entry Criteria: Evaluated sequentially at each subsequent approval step. Step criteria allow multi-tiered branching. For instance, Step 1 may require manager signoff for any discount over 15%, while Step 2 requires Vice President signoff only if the discount exceeds 30%. If a record does not meet an individual step's criteria, the process executes the configured fallback behavior: Approve the record , Reject the record , or Skip directly to the next step .
Approver Assignment Options & Routing Mechanisms
When defining an approval step, the app builder configures how the platform identifies the approving authority. Salesforce provides five distinct approver routing mechanisms:
1. Automatically Assign to User(s)
The step explicitly assigns the approval request to one or more named Salesforce users. This is ideal for static, centralized signoffs, such as routing all capital expenditure requests to a specific Chief Financial Officer or Legal Counsel.
2. Automatically Assign to Queue
Instead of naming individual users, the step assigns the request to a Queue . Any member of the queue can review, accept, and approve or reject the request.
Important
Queue Approver Object Limitations: A Queue can only be assigned as an approver if the underlying sObject supports queue ownership. Supported objects include Lead , Case , and supported Custom Objects . Standard objects such as Account , Contact , and Opportunity do not support queues, and therefore cannot route approval steps to queues. Attempting to assign an Opportunity approval step to a queue is a standard certification exam trap.
3. User Manager Hierarchy
The platform dynamically identifies the approver by inspecting the standard Manager lookup field on the submitter's User record ( User.ManagerId ). This enables automated hierarchical routing without hardcoding user IDs. If multi-level escalation is required, subsequent steps can traverse up the managerial chain.
4. Custom Hierarchical Relationship Fields
Organizations frequently maintain parallel approval chains that do not align with direct administrative reporting structures. For example, financial signoffs may follow a dedicated Finance Director rather than an employee's direct HR manager.
Salesforce solves this by allowing administrators to create Hierarchical Relationship Fields on the standard User object (e.g., User.Expense_Approver__c or User.Regional_VP__c ). During step configuration, the approval process can route requests dynamically based on the value populated in this custom hierarchical field.
5. Submitter Chooses the Approver Manually
The process prompts the submitting user at runtime to manually search for and select an active user to evaluate the request. While flexible, this approach introduces human error and lacks strict compliance controls.
Parallel Approvals: First Response vs. Unanimous Consensus
When an approval step assigns a request to multiple individual users (up to a platform limit of 25 approvers per step ), the app builder must select one of two parallel approval behaviors: PARALLEL APPROVAL OPTIONS
- │
- ┌────────────────────────────┴────────────────────────────┐
- ▼ ▼
- ┌───────────────────────────────┐ ┌───────────────────────────────┐
- │ FIRST RESPONSE WINS │ │ UNANIMOUS CONSENSUS │
- ├───────────────────────────────┤ ├───────────────────────────────┤
- │ • Up to 25 approvers assigned │ │ • Up to 25 approvers assigned │
- │ • FIRST action determines step│ │ • ALL approvers must approve │
- │ • If User A Approves -> Step │ │ • If User A, B approve and │
- │ approved; others discarded │ │ User C Rejects -> REJECTED │
- │ • Common for regional peer │ │ • Common for legal, security, │
- │ triage and fast turnaround │ │ and compliance signoffs │
- └───────────────────────────────┘ └───────────────────────────────┘
Approve or Reject based on the FIRST response: The approval request is dispatched simultaneously to all assigned approvers. As soon as any single approver approves or rejects the record, the step immediately concludes with that outcome. The remaining pending requests are canceled. This pattern is ideal when multiple team members possess equal authority and quick turnaround is paramount.
Require UNANIMOUS approval from all selected approvers: Every single assigned approver must explicitly cast an approval vote. If even one approver rejects the request, the step immediately fails and triggers the rejection sequence. The order in which the approvers respond does not matter, but full consensus is mandatory. This pattern is standard for sensitive legal, compliance, or information security audits.
Approver Routing Methods Comparison Matrix
Routing Method Configuration Location Supported Objects Multi-User Behavior Typical Business Scenario
Named User(s) Step Setup (Explicit selection) All Objects Up to 25 users (Unanimous or First Response) Legal counsel review, CFO expenditure signoff
Queue Step Setup (Queue selection) Supported queue-enabled objects, including custom objects, Cases, and Leads Any queue member can take ownership and act Tier-1 support escalation, shared billing review
Manager Field User Record ( ManagerId ) All Objects 1:1 Manager routing per step Standard expense report or travel authorization
Hierarchical Field Custom field on User object All Objects 1:1 Custom manager routing per step Matrix organizations with distinct functional approvers
Manual Selection Submitter prompt at runtime All Objects Single user selected by submitter Ad-hoc peer code review or informal project signoff
Delegated Approvers & Reassignment Governance
To prevent operational bottlenecks when designated approvers take planned leaves of absence or unexpected medical leave, Salesforce provides Delegated Approvers :
Configuration: A Delegated Approver is designated in the Approver Settings section of an individual's User record ( User.DelegatedApproverId ). It is configured per user, not globally per approval process.
Operational Capabilities: When an approval request is assigned to a manager, their delegate, when allowed by the approval step, receives access to view, approve, or reject the pending approval request on their behalf.
Crucial Administrative Limitation: A Delegated Approver cannot reassign an approval request to someone else. Only the originally assigned approver and users with the System Administrator profile (or 'Modify All Data' / 'Modify All' object permissions) can reassign approval requests.
Notification Nuance: By default, approval notification emails are routed to the assigned approver. To ensure delegated approvers receive email alerts, the user or administrator must verify the Receive Approval Request Emails preference on the user profile is set to notify delegated approvers.
Best Practices & Common Exam Traps
Note
Process Immutability: Once an approval process is activated, you cannot add, remove, or reorder approval steps. To alter the step topology of an active approval process, an app builder must click Clone , create a new inactive version, introduce the necessary steps, and activate the cloned version.
Tip
Automated Submission via Flow: Users frequently forget to click the native 'Submit for Approval' button. App builders can eliminate manual friction by using a Record-Triggered Flow with a Submit for Approval core action to automatically submit records into the pipeline when qualifying criteria are met.
Important
Deleting Approval Processes: You cannot delete an approval process that is active or contains active/pending approval requests. You must first deactivate the process and ensure all pending records are approved, rejected, or recalled.
Common Exam Traps
Trap 1: Attempting to assign an Opportunity approval step to a Queue. Opportunities do not support Queues. If an exam question describes routing an Opportunity discount to a shared sales operations team, the correct solution involves either parallel user approval or a custom routing architecture, never an Opportunity queue.
Trap 2: Assuming Delegated Approvers can reassign requests. A Delegated Approver can only approve or reject; they can never reassign an approval request to a third party.
Trap 3: Confusing Entry Criteria with Step Criteria. If a record fails the main Approval Process Entry Criteria, it never enters the process and no actions fire. If it enters the process but fails an individual step's criteria, it can skip to the next step without failing the overall approval.
Official Source Check
Checked October 19, 2026: Classic step approvers and delegation .