7.1 Multi-Step Approval Processes & Approver Routing

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.

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:

1. 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.
2. 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.

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     │
└───────────────────────────────┘         └───────────────────────────────┘

1. 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.
2. 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

---

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

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.