Salesforce Approval Processes Explained: Native, Custom & Flow Approvals

💬 In plain words: An approval process routes a record up the chain of command. The moment you submit a record, it locks. Approvers then take action, triggering final approval or rejection steps. For interviews, know two things cold: the record locks during the process, and approval actions sit separately from the standard save order.

📌 Real-life Example: Imagine a sales quote. Discounts over 15% require manager sign-off, while discounts over 30% need the Finance team's approval too. You can handle this with a single approval process containing two conditional steps. While the quote awaits approval, it is locked. If the sales rep tries to tweak the price, they'll find out quickly that locking is standard behavior.

Core Concept

The standard Salesforce Approval Process is a native declarative routing engine. Here is how it operates under the hood:

• Entry & Routing: A record enters the process based on predefined criteria. It then routes through one or more approval steps.
• Approver Resolution: Each step assigns the request to specific users, queues, related user fields, or dynamic approvers mapped via the role hierarchy or Apex.
• Automated Actions: The engine executes distinct actions at different phases: Initial Submission, Final Approval, Final Rejection, and Recall. These actions can be field updates, email alerts, outbound messages, tasks, or triggering flows.
• Record Locking: While pending approval, the record is locked to maintain data integrity. By default, only designated approvers and System Administrators can edit it.
• Order of Execution: Submitting a record for approval is a distinct action. It is not part of the standard record save lifecycle.
• Scalability Limits: When business logic requires dynamic matrices, parallel approvals with quorums, or highly customized config, teams often outgrow this native engine and build a custom Apex-and-Flow solution instead.

🧠 Core Takeaway: Submit → Check Entry Criteria → Route to Steps (User/Queue/Dynamic) → Execute Actions (Initial/Approve/Reject/Recall). The record ALWAYS locks. When native limits hold you back, switch to a custom engine.

🧭 360 Card — Approval Processes

• Rule: Submit, lock, route, act. The lock is the crucial mechanic that trips up new developers.
• Gain: A powerful declarative routing engine out-of-the-box. No custom code needed for standard sequential approvals.
• Price: The strict lock. The owner loses edit access, and a departed employee can strand a pending record.
• Limits: Admins (or users with Modify All) can bypass the lock. However, advanced routing like parallel quorums, complex matrix resolution, and line-item approvals cannot be handled natively.
• Mirror (Flow Approvals): Salesforce's modern approach uses Flow Orchestration to manage approvals. Use this when you need highly configurable, non-linear routing.
• Future Proofing: Once you outgrow the native engine, you aren't just building an automation—you're building an approval product. Always explore Flow Orchestration before writing custom Apex from scratch.
• At Volume: Approval steps generate sharing rows for approvers and revoke them afterward. Thousands of pending requests mean thousands of active, churning share grants, which can impact performance.

⚠ INTERVIEW TRAP: Do not confuse approvals with DML saves. Submitting for approval is a separate, dedicated action. It exists completely outside the standard Salesforce Order of Execution.

Core Q&A

Q: Design an approval flow where deals over $50k need manager approval, over $500k need VP approval, and the record must lock during review.

🎯 Say this first: "I would build one approval process with two steps, utilizing amount-based entry and step criteria. The record lock is handled automatically as standard behavior."

A: You need a single approval process with an initial entry criteria of Amount > 50000. Inside, configure two routing steps:

• Step 1: Routes to the submitter's direct manager (using a related-user field or the role hierarchy).
• Step 2: Has its own step-entry criteria of Amount > 500000, routing to the VP. Small deals will automatically exit after Step 1, while massive deals proceed to Step 2.
• Locking: This is enabled by default. Only designated approvers and admins will retain edit rights.
• Actions: The Initial Submission Action updates the status to In Review. The Final Approval Action sets the status to Approved and fires an email alert. The Rejection Action unlocks and reopens the record.

If the business asks for something more complex later—like matrix-based approvers or a parallel quorum—that is the exact moment to pivot from standard config to a custom Apex-plus-Flow engine.

Scenario-Based Follow-ups

Q1: A record is stuck "In Approval" and cannot be edited. The assigned approver just left the company. What are the recovery options?

A1: The native process has successfully locked the record, but you have three ways to recover it:

• Admin Override: System Administrators (or any user with Modify All on the object) can still edit the locked record, or manually recall/reassign the request.
• Reassign: Navigate to the Approval History related list and reassign the pending step to a different, active user.
• Recall: Recall the submission entirely. This unlocks the record so the owner can submit it fresh.

Pro Tip: To prevent this from happening in the future, route approvals to Queues rather than named individuals. If one person leaves, the rest of the queue can still claim and approve the record. Setting up delegated approvers is another strong safety net.

Q2: At what point do you abandon native Approval Processes and build a custom engine?

A2: You go custom the minute native limitations block business requirements. Classic triggers include:

• Parallel Quorums: E.g., routing to 5 people where any 3 must approve.
• Matrix Approvals: When approvers are resolved dynamically through complex custom data tables.
• Child Record granularity: Per-line-item approvals (like approving individual quote lines instead of the whole quote).
• Business User Maintenance: If the business demands that sales managers update approval routing rules without touching setup metadata. (Native processes require "Customize Application" permissions to edit).

A custom engine usually relies on custom metadata to store the rules, Apex to evaluate those rules and manage sharing grants, and Flow to provide the user interface. It trades upfront build time for infinite flexibility.

Q3: What are "Flow Approval Processes" and do they replace classic ones?

A3: Introduced around Spring/Summer '25, Flow Approval Processes are a massive upgrade. They are native approval workflows built directly on top of Flow Orchestration.

• They operate using Stages (which run sequentially) and Steps (which can run in parallel).
• An approval step assigns a work item to a user, group, or queue via a Screen Flow. Background steps can handle automated logic via Autolaunched Flows.
• They include a dedicated Approvals App to easily manage submissions.
• The Impact: Requirements that used to force developers into writing custom Apex (like parallel routing or highly conditional paths) can now be handled declaratively.

The Verdict: Classic approval processes aren't going anywhere, but you should default to Flow Approvals for any net-new builds. Only write custom Apex when the requirements exceed even what Flow Orchestration can handle.