Mastering Salesforce Administration: Part 4 - Approval Process

Updated 26/02/2026

You’ve built the foundations: a healthy org, clear UX, and automation that moves work forward. Now it’s time to put governance and decision‑making on autopilot. Approvals are where business policy, auditability, and user experience meet. They turn human decisions into reliable, traceable processes that keep deals moving, expenses controlled, and compliance intact.

This chapter shows how to design and operate approval processes that are robust, transparent, and maintainable. You’ll learn how to translate business rules into entry criteria and routing logic, how to choose between Flow, Classic, and programmatic approaches, and how to build for scale, exceptions, and recovery. Practical patterns, testing strategies, and reporting are emphasised so your approvals don’t become bottlenecks or technical debt.

For admins and developers alike, approvals are essential knowledge: they show how transactions lock and unlock, how state is modelled and audited, and how business rules translate into routable, traceable processes. Working with approvals teaches practical Flow patterns and when to extend them with Apex, so you can choose the simplest declarative solution that meets requirements and only add code when necessary.

✅ Adding a governance layer with Approval Processes

Approval processes add a governance layer on top of standard data operations, validation rules, and automation. They handle situations where a business decision needs explicit human sign‑off and a clear audit trail. Instead of relying on informal communication or ad‑hoc checks, an approval process establishes a clear path for review, routing, and follow‑up actions. That path is enforced when a record is submitted to an active approval process and can be affected by record‑locking settings, user permissions, and other automation.

In day‑to‑day work, approvals sit alongside Flow, validation rules, and Apex as part of the broader automation landscape. Each tool addresses a different aspect of system behaviour. Validation rules enforce data quality. Flow manages logic and orchestration. Apex supports specialised or high‑scale scenarios. Approval processes focus on the human decision points the system cannot resolve on its own.

Most teams use approvals for decisions that carry financial, operational, or compliance impact. They ensure sensitive changes are reviewed by the right people and that the organisation can demonstrate how and when those decisions were made. They also coordinate actions that depend on a confirmed outcome, such as updating fields, notifying teams, or triggering downstream automation.

This guide assumes you are already comfortable with objects, security, email templates, and the basics of Flow. Later in the guide you will revisit approvals from a developer perspective, including programmatic submission, orchestration patterns, and how approvals behave inside larger automation designs.

🔎 Conceptual overview

An approval process automates how specific people review and sign off on a record. It defines which records can enter the flow, the sequence of approval steps, who can act at each step, and the automated actions that run when a request is submitted, approved, rejected, recalled, or reassigned. At runtime Salesforce creates approval‑related records (ProcessInstance and related work items) so each decision is recorded with actor, timestamp, and outcome, producing an auditable lifecycle.

Salesforce supports two ways to build approvals: classic Approval Processes (legacy workflow engine) and Flow Approval Processes (modern Flow based). Both follow the same pattern: a record enters an approval lifecycle, moves through decision points, and produces an auditable trail.

Classic processes use steps to define criteria and approvers. Flow processes use stages for richer logic and branching. Actions include record locking, notifications, and field updates.

Approval patterns appear in scenarios like discount approvals, contracts, expenses, and HR requests, especially in regulated environments needing audit trails.

🛤️ Approvals in the automation landscape

Approvals sit at a distinct layer in Salesforce’s automation toolkit, complementing validation rules, Flows, and other automation tools. They add governance for decisions that require human judgment, handling scenarios that hard data rules and no-touch automation cannot resolve on their own.

Distinction from other automation

The table below compares approval processes to two other Salesforce other automation tools and looks at the role each plays:

Tool	When it runs	What it does	Human involvement	Governance value
Validation Rules	On save	Enforce data integrity by blocking invalid changes	None	Data correctness
Record‑Triggered Flow / Workflow	On data change	Automate updates, notifications, and logic	None	Operational automation
Approval Processes (Classic or Flow)	When a record is submitted	Capture explicit approve/reject decisions; route to approvers; run related actions	Required	Decision traceability and auditability

Approval processes apply when a human must make an approve or reject decision that the system cannot resolve automatically. Features such as record locking, notifications, and downstream automation support the approval lifecycle and help ensure the decision is captured and auditable.

Enforcement and practical notes

Approvals enforce only after a record is submitted. Record locking can prevent UI edits while a request is pending, but high‑privilege users (such as those with Modify All) and automation can still bypass restrictions unless complementary controls—validation rules, Apex checks, or integration safeguards—are in place. Always test privilege and integration scenarios in a sandbox to confirm behaviour.

A simple way to visualise the landscape is:

Validation Rules → enforce hard data rules
Approvals → govern human decisions

🔄 Classic vs Flow vs Custom Approaches

Now that you understand how approvals fit in the automation ecosystem, you have three main approaches to choose from. Your decision depends on your requirements’ complexity, the need for integration, and your long-term strategy.

Classic Approval Processes → Structured approval paths configured in Setup. Best for linear, predictable approval chains and existing implementations.
Flow Approval Processes → The modern pattern for approvals. Built in Flow using stages, with richer branching, orchestration, and integration options. Recommended for new implementations and complex, multi‑team scenarios.
Custom Flows or Apex → Used only when approval requirements fall outside the standard model (for example, highly dynamic routing, custom UI, or non‑record‑based approvals). These approaches lack built‑in audit trails and governance features, so they should be chosen deliberately.

Salesforce’s strategic direction is clear: Flow is the primary declarative automation tool, and Flow Approval Processes are the long‑term model for approvals.

🧩 Core approval concepts and terminology

Before building an approval process, it helps to understand the vocabulary and lifecycle that govern how approvals behave at runtime. These concepts form the foundation for designing and troubleshooting approval behaviour.

The approval lifecycle

An approval process is the overall definition of the approval workflow for a given object. It defines which records are eligible to enter the approval flow (entry criteria) and who can initiate submission (initial submitter). It also outlines the sequence of decision points the record must traverse (approval chain), the actions that run on approval, rejection, recall, or reassignment, and how the record behaves while locked. A critical part of the approval process definition is record behaviour: whether the record is locked during the approval and who can edit it (typically, administrators can override locks, while regular users cannot edit locked records without explicit permissions).

When a record is submitted to an approval process, Salesforce creates an approval request (also called a work item) that routes to the designated approvers. This request is recorded in the ProcessInstance and ProcessInstanceWorkitem records, creating an auditable trail with timestamps, actor names, and outcomes. At runtime, Salesforce tracks the lifecycle of each approval request to ensure compliance and provide visibility. In Flow Approval Processes, the same lifecycle is tracked through Flow runtime data rather than ProcessInstance records, but the audit principles remain identical.

The sequential decision points

An approval step (called a stage in Flow Approval Processes) is a single decision point in the chain. Each step answers: “Does this record meet the criteria to move forward, and if so, who should approve it?” A step can have criteria (for example, only records over $50,000 need VP approval), an assigned approver or queue, and escalation rules if the approver doesn’t respond within an SLA.

Steps are evaluated in order. If a record meets the criteria for a step, the approval request goes to the designated approver. If it doesn’t meet criteria, Salesforce moves to the next step. This branching allows you to route different records through different approval chains based on amount, region, type, or any field value.

In Flow Approval Processes, stages can run sequentially or in parallel, allowing multiple approvers or teams to act concurrently.

Approvers and delegated approvers

Each step or stage assigns one or more approvers. Approvers can be designated in several ways:

A specific user → a named individual in your org.
A role or role hierarchy → all users in a given role, or users above in the role hierarchy (useful for manager chains).
A queue → a group of users sharing a queue, so any queue member can act on the request.
A related user → determined dynamically from the record itself, such as the submitter’s manager field or a field pointing to another user (e.g., “Account Owner”).
Dynamically determined approvers → via formula or field value, allowing the system to select the approver based on record data at runtime.

In Flow Approval Processes, approvers can also be resolved dynamically through variables or subflows, enabling context‑aware routing.

If delegated approvers are enabled in your approval process configuration, a primary approver can delegate their approval authority to another user, who then acts on behalf of the primary approver. This flexibility is particularly useful when approvers are unavailable.

Actions and outcomes

An approval action is an automated response that executes at key points in the approval lifecycle. Actions run at different stages:

Initial submission actions → triggered when a record is first submitted for approval (e.g., sending an initial notification, locking the record).
Step‑level actions → execute when an approver at that step approves or rejects the request (e.g., updating a status field, sending an alert to the approver’s manager).
Final approval actions → run when the entire approval process is approved (e.g., changing a record status to “Approved,” notifying stakeholders, creating tasks for follow‑up teams).
Final rejection actions → run when the process ends in rejection (e.g., updating the record to “Needs Revision,” notifying the submitter, assigning a task).
Recall actions → triggered if the submitter recalls the approval request (e.g., resetting the status, notifying approvers).

These actions can include field updates, email alerts, tasks, outbound messages, and Flow-triggered automation. When an approver acts on a work item by approving, rejecting, reassigning, or recalling it, Salesforce records that action on the ProcessInstance and executes the corresponding actions. Record locking during the approval process also influences who can edit the record: administrators with “Modify All” can typically override locks, and users with specific edit permissions depend on your field-level security and approval process settings. In Flow Approval Processes, actions can also invoke subflows or orchestration steps, extending automation beyond the record itself.

Approval request / work item

An approval request (also called a work item) is the individual decision task routed to an approver. In the data model, this is represented as a ProcessInstanceWorkitem record. A work item can be:

Approved → the approver signs off on the request, triggering final approval actions.
Rejected → the approver denies the request, triggering final rejection actions.
Reassigned → transferred to another approver (useful when an approver is unavailable).
Recalled → the original submitter can withdraw the request (if allowed), triggering recall actions.

In Flow Approval Processes, work items are represented as Flow runtime tasks rather than ProcessInstanceWorkitem records, but they follow the same approve/reject/reassign/recall pattern.

Each action is logged with the actor’s name, timestamp, and comments, forming part of the auditable approval history. This record of decisions and timing is essential for compliance and troubleshooting.

Putting it all together

The approval lifecycle flows like this:

Record meets entry criteria
Submitter clicks “Submit for Approval” or the system auto-submits
Salesforce creates a ProcessInstance and a ProcessInstanceWorkitem
The work item routes to the first approver assigned to the step or stage
The approver approves or rejects the request
Salesforce executes step level or final actions based on the outcome
The record advances, completes, or is rejected depending on the decision and process design

Throughout, every decision and timestamp is logged for audit and reporting. Together, these elements ensure every decision is traceable, auditable, and governed by explicit configuration.

This vocabulary carries through both Classic and Flow Approval Processes; the mechanics differ slightly, but the conceptual model remains the same.

📐 Designing the process before you build

The gap between a well‑designed approval process and a broken one isn’t complexity, it is how deeply you understand the business process before configuring anything in Salesforce. Building without a clear design leads to delays, rework, and frustrated users waiting for fixes while approvals sit in limbo. Taking time upfront to map the logic, identify stakeholders, and document your design prevents these problems and gives you a blueprint anyone can maintain or troubleshoot later.

Salesforce’s own guidance emphasises this step‑first philosophy. Before you open Setup or Flow Builder, you need clarity on who makes decisions, when they make them, what criteria trigger each decision point, and what actions follow each outcome. This section walks through that design process using a practical framework.

Map the business process end to end

Start by sketching the complete approval journey from the user’s perspective. This doesn’t need to be formal, a whiteboard flowchart or written outline is enough. The goal is to answer some core questions:

Who can submit a record for approval? Only the record owner; anyone who can edit; specific role(s); or a defined group This becomes your “initial submitter” setting.
When should a record be submitted? Manual or automatic? This affects whether you use a screen flow, record‑triggered Flow, or a standard submit action.
What conditions trigger the approval process? For example, “only opportunities over $500,000” or “contracts in ‘Ready for Review’ status.” These become your entry criteria.
Who must approve, and in what order? Single approver, sequential steps, or parallel stages (supported in Flow Approval Processes)? Does routing depend on record data?
What happens when someone approves or rejects? Status changes, notifications, follow‑up tasks, or downstream automation such as subflows or billing updates.
Are there exception paths? Can the submitter revise and resubmit? Should escalations occur if an approver doesn’t respond within an SLA?

Working through these questions forces you to consider both the happy path and edge cases andambiguities surface early.

Work through the official design considerations

Salesforce provides a comprehensive set of design questions in their Setup wizard that cover everything from email templates and delegation rules to wireless approval options and auto approval scenarios. While you don’t need to answer every one during initial design, they serve as a reminder that approvals touch many aspects of the user experience, from how notifications are sent to whether records can be edited during approval. Use them as a checklist to ensure you haven’t missed any practical details, but focus first on the business logic above.

Document your design with these artifacts

Before building anything in Salesforce, create these design artifacts:

1. Process flowchart
A simple diagram showing steps, decision points, and outcomes. This often becomes the blueprint for your Flow stages or classic approval steps.

Example structure:
Record created → [Meets entry criteria?] → Yes → Submit for Approval → Step 1 Approver → [Approved?] → Yes → Final actions → Complete; No → Reject and notify.

2. RACI matrix (Responsible, Accountable, Consulted, Informed)
Clarifies who performs actions, who owns the process, who provides input, and who needs visibility. This prevents surprises after go‑live.

3. Approval routing matrix
A table showing which records route to which approvers based on criteria:

Record Criteria	Step 1 Approver	Step 2 Approver	Approval SLA
Discount < 10%	Manager	—	2 business days
Discount 10–20%	Manager	Director	3 business days
Discount > 20%	Director	VP Finance	5 business days

4. Data model notes
Document fields used for criteria, fields updated on approval, and what each status value means.
Also confirm field‑level security and record‑locking behaviour early, they affect runtime permissions.

Why this design work saves time later

While the time spent on design varies with the process complexity (simple approvals might take a few hours, while complex multi-team workflows could require days) it always prevents far more time in rework, troubleshooting, and frustrated users later. When others need to maintain or troubleshoot the process, they have clear documentation as a reference for how it should behave. When new requirements appear (“We also need VP sign‑off for contracts over $1M”), you can evaluate them against the documented design instead of patching blindly. And when something goes wrong, your flowchart and matrices let you diagnose methodically rather than guessing.

✍️ Classic Approval Processes: overview and components

Classic Approval Processes are Salesforce’s legacy approval engine, configured entirely in Setup. They remain widely used because they are simple to configure, easy to understand, and reliable for many standard approval chains, especially those that are linear, object‑specific, and don’t require complex branching or cross‑object orchestration.

You create a classic approval process in Setup by navigating to Setup → Approval Processes, selecting the object, and choosing Create New Approval Process. The Standard Setup Wizard guides you through the key decisions, which makes Classic a good first implementation when you are learning the approval model or working with straightforward requirements.

The core configuration points in a Classic Approval Process are:

Object and entry criteria — Define which records are eligible to enter the process. This prevents unnecessary approval requests and keeps queues clean. Common criteria include record type, status, amount thresholds, or a custom “Ready for Approval” flag.
Initial submitter — Specify who can submit a record for approval: the record owner, any user with edit rights, or a restricted set of users. This determines who can initiate the approval lifecycle.
Next Automated Approver — A fallback approver used when a step cannot determine an approver (for example, if a manager field is blank). This is not the same as step routing, but it ensures the process does not fail silently.
Approval steps — Each step defines its own entry criteria and assigned approvers. Approvers can be a manager, a custom hierarchy field, a specific user, a queue, or a related user lookup. Steps run sequentially and cannot run in parallel.
Record editability — Choose whether the record is locked while the approval request is pending. Locking is the default because it preserves data integrity during decision‑making, but you can allow edits if business requirements demand it. Administrators with broad permissions can typically override locks.
Initial submission and final approval/rejection actions — Configure the automation that runs at the start and end of the process. Actions include email alerts, field updates, task creation, and outbound messages. These actions communicate outcomes and trigger downstream processes.

Classic Approval Processes aren’t as flexible as Flow Approval Processes, but they remain a strong choice for straightforward approvals in established orgs and scenarios where transparency and maintainability matter more than advanced branching. They also use the long‑standing ProcessInstance and ProcessInstanceWorkitem records, which provide a familiar audit trail for admins who have worked with approvals for years.

If you want a practical Trailhead walkthrough, you can also learn more about approval processes in the module Approve Records with Approval Processes.

Approve Records with Approval Processes Ensure that critical records are reviewed by the right people at the right time.

📋 Classic Approval Processes: step-by-step build

To see how this works in practice, we’ll build a straightforward approval: discount approvals on Opportunities. This example is common in sales orgs because discounts carry revenue impact and need appropriate sign‑off. The process uses a single approval step where the opportunity owner’s manager approves discount requests.

Step 1: Create the Approval Process definition

Navigate to Setup → Approval Processes, select Opportunity, and click Create New Approval Process. The Standard Setup Wizard opens and guides you through the configuration.

Process name and description

Choose a clear, role‑agnostic name like Opportunity Discount Approval and add a short purpose: “Routes opportunities with requested discounts ≥ 10% to the opportunity owner’s manager for approval.”

Entry criteria

Define which records enter this process. Example:

Field: Discount_Requested__c
Condition: greater than or equal to
Value: 10

Initial submitter

Specify who can submit records (typically Record Owner). You can tighten this to specific users or roles if needed.

Record editability

Decide whether the record is locked while the approval is pending. Locking preserves data integrity; if you allow edits, document who may edit and consider complementary validation rules or Apex checks because admins and automation can bypass locks.

Next Automated Approver

Set a fallback approver (for example, Role: Sales Manager) to prevent the process from failing if a step cannot resolve an approver (e.g., blank manager field).

Initial submission actions

Common actions: lock the record (if Record Editability is set to Read Only) and send an email alert to the assigned approver.

Step 2: Add approval steps

On the process detail page, go to Approval Steps → Add Approval Step.

Step name and description

Use a descriptive name such as Manager Approval and add context: “Manager reviews discount request and approves or rejects.”

Step entry criteria

Choose whether the step applies to all requests or only those meeting specific criteria. Steps can have their own entry criteria (useful for tiered routing).

Approval step assignment

Approvers can be:

Manager of the record owner (recommended for manager routing)
Specific user (not recommended for scaling)
Related user from the record (e.g., Approver__c)
Queue or custom hierarchy (custom lookup)

For this example, select Manager of the record owner.

Multiple approvers in this step

You can require unanimous approval or allow the first response to decide. For simplicity, use a single approver.

Assign the step to multiple approvers

Choose “Let the submitter choose” for flexibility, or pre-assign multiple users/queues.

Step 3: Add workflow actions

Configure actions that run when the record enters the step and when the approver acts.

Initial submission actions

Field update: Approval_Status__c = "Pending Manager Approval"
Email alert: templated email to the approver with a link and summary

Step approval actions

Field update: Approval_Status__c = "Approved"
Field update: Discount_Approved__c = TRUE
Email alert: notify the sales rep
Task (optional): create a follow‑up for finance

Step rejection actions

Field update: Approval_Status__c = "Rejected"
Email alert: notify the sales rep with next steps
Task: create a task for the rep to revise and resubmit (if allowed)

Step 4: Configure final approval/rejection actions

Final approval actions

Field updates: Discount_Approved__c = TRUE; Approved_Date__c = TODAY()
Email alerts: notify sales rep and manager
Outbound Message (optional): trigger external systems via SOAP/REST

Final rejection actions

Email alert: notify the sales rep with guidance
Task: create a follow‑up task

Step 5: Activate and test

Save and activate, then test thoroughly:

Create a test opportunity with Discount_Requested__c >= 10
Impersonate or test as the sales rep and Submit for Approval
As the manager, find the item in Salesforce Home → Items to Approve and act on it
Verify field updates, emails, tasks, and the approval history related list
Test edge cases: missing manager, delegated approver, and SLA escalations

Key practices for building Classic Approval Processes

Keep entry criteria simple to reduce maintenance overhead.
Use fields, not people names; prefer manager fields and role hierarchies.
Test in a sandbox with users in different roles and delegated approvers.
Reuse templates and status fields to avoid duplication.
Document decision points with a flowchart and routing matrix.
Confirm field‑level security and record‑locking behaviour early.

This single‑step discount approval is a foundation you can extend with multi‑step approvals, parallel approvers, and escalations as your org’s needs grow.

For more detail on building approval processes, see the Salesforce guide to Create Approval Processes. For a hands-on walkthrough, try the Build a Discount Approval Process project on Trailhead. The follow it up with the Approval Process Management and Approval Process Troubleshooting Superbadges.

Create Approval Processes An approval process automates how records are approved. You can create an approval process for a task, email alert, field update, or outbound message.

Build a Discount Approval Process Make it easy for your sales reps to get the approvals they need for discount offers.

Superbadge: Approval Process Management Demonstrate your ability to automate and enhance approval processes.

Superbadge: Approval Process Troubleshooting Use your approval process troubleshooting skills to increase productivity.

🔄 Classic approvals: advanced step patterns

As your approval requirements grow beyond a simple linear chain, you’ll run into patterns that are common in real orgs: multi-step routing with different approvers at different tiers, multiple approval processes on the same object, and decisions about how strictly to control who must approve and in what order. This section covers the most common advanced patterns and shows how to use them cleanly in Classic Approval Processes.

Multi-step approvals with narrow vs broad ordering

The discount approval you built earlier had a single step: manager review. But many orgs need multiple approval tiers, each applying different business rules. The key design question is: do you put the most restrictive conditions first, or do you begin with a general approval and add specialist review later?

A useful way to think about this is narrow-to-broad versus broad-to-narrow ordering.

Narrow-to-broad ordering: specific criteria first

In a narrow-to-broad design, you place the most specific or highest risk conditions earlier in the approval path. This works well when certain records should escalate immediately to a more senior approver instead of passing through lower tiers first.

Example: tiered discount approval

Step 1 (High Discount): Entry criteria Discount_Percentage__c >= 20 → Routes to VP Finance
Step 2 (Medium Discount): Entry criteria Discount_Percentage__c >= 10 AND Discount_Percentage__c < 20 → Routes to Director of Sales
Step 3 (Low Discount): Entry criteria Discount_Percentage__c < 10 → Routes to Sales Manager

This pattern is useful when your business rules create clear risk bands. High risk requests are reviewed by senior approvers straight away, while lower risk requests stay with the appropriate lower tier.

Broad-to-narrow ordering: general review first, then conditional review

In a broad-to-narrow design, you start with a general approver who reviews all records, then add later steps that apply only when additional conditions are met. This is useful when every record needs one universal gate, but only some need further specialist review.

Example: contract approval with conditional specialist review

Step 1 (General Legal Review): Applies to all records → Routes to Legal Reviewer
Step 2 (High Value Review): Entry criteria Contract_Amount__c > 500000 → Routes to VP Contract Management
Step 3 (International Review): Entry criteria Account_Country__c != 'USA' → Routes to International Compliance Officer

In this design, every contract goes through legal review first. After that, Salesforce evaluates the later approval steps according to their configured criteria. High value or international contracts may require additional approvals before the process completes.

This pattern works well when you want one universal control point, then targeted specialist review only where needed. The tradeoff is that records meeting multiple conditions may take longer to get fully approved, so it’s best used where that extra rigor is justified.

Multiple approval processes on the same object

As your org grows, you may find that different business units or regions need fundamentally different approval logic on the same object. In that case, it is often better to create multiple approval processes on one object rather than force everything into one oversized process.

Classic Approval Processes allow multiple approval processes for the same object. Salesforce evaluates them in the order you define, and the record enters the first active process whose entry criteria match.

When to use multiple processes

Example: regional discount approval

Your org operates in North America and Europe, and each region uses different approvers and routing logic. Instead of creating one very large process with complex branching, you create two separate approval processes.

Process 1: North America Discount Approval

Entry criteria: BillingCountry = 'USA' OR BillingCountry = 'Canada' OR BillingCountry = 'Mexico'
Approvers: Manager → Director (North America roles)

Process 2: Europe Discount Approval

Entry criteria: country belongs to your Europe criteria set
Approvers: Regional Manager → VP Europe

When a Canadian opportunity is submitted, Salesforce evaluates the active processes in order and uses the first one whose entry criteria match. A French opportunity would match the Europe process instead.

This approach keeps each process simpler, clearer, and easier to maintain.

How Salesforce evaluates multiple processes

In Setup, you control the order of approval processes for an object. Salesforce evaluates them from top to bottom. The first process whose entry criteria match is the one the record is submitted into.

That means ordering matters. Put your most specific approval processes above broader or catch all ones. Even better, ensure the entry criteria is mutually exclusive.

Advantages of multiple processes over one monolithic process

Clarity: Smaller processes are easier to explain to stakeholders and auditors.
Ownership: Different teams can manage their own approval logic more safely.
Maintainability: Simpler criteria and cleaner step design reduce admin overhead.
Testing: Focused processes are easier to test and troubleshoot.

Multiple approvers in a single step

Classic Approval Processes do not support parallel approval stages in the modern Flow sense, but they do support multiple approvers within a single step. This lets you decide whether one person’s response is enough or whether everyone assigned must approve.

First response decides vs all must approve

When you configure multiple approvers for a step, the main options are:

First Response Decides
Any one of the assigned approvers can approve or reject the step. As soon as one approver acts, the step is complete. This is useful when a group of peers can all make the same decision and you want the process to move quickly.

All Must Approve
Every assigned approver must approve the step for it to pass. If any approver rejects, the step and the overall approval process are rejected. This is useful when you need explicit sign-off from multiple stakeholders.

Example: first response from an approval queue

Suppose your sales org uses a queue based approval team for routine discount decisions. The approval request goes to the Sales Approval Queue, and several managers are members of that queue. The first available manager can review and decide the request.

A typical setup would be:

Create a queue that includes the relevant managers.
Configure the approval step to assign the request to that queue or group based approver path.
Choose First Response Decides so the step completes as soon as one manager acts.

This pattern helps avoid bottlenecks and allows peer coverage during leave or busy periods.

Considerations and tradeoffs

First Response Decides is faster, but you need confidence that any of the assigned approvers can make the decision appropriately.

All Must Approve gives stronger control and broader agreement, but it can slow the process down significantly if one approver is unavailable.

For routine operational approvals, first response patterns often reduce friction. For sensitive financial, legal, or compliance decisions, all must approve may be more appropriate.

Dynamic approvers: following roles and relationships instead of hardcoding people

One of the biggest maintenance problems in approval processes is hardcoding specific users into the step definition. When someone changes roles or leaves the organisation, the process needs manual repair. A better approach is to use dynamic approvers wherever possible.

Manager hierarchy: the standard pattern

The most common and recommended approach is routing to the Manager in the standard Salesforce user hierarchy. Salesforce looks up the appropriate manager and sends the approval request there.

That’s the pattern you used earlier in the single step discount example. It is simple, resilient, and usually the right default for manager based approvals.

Another common approach is routing based on a user lookup or other supported field relationship.

Example: a custom contract object includes an Approver__c lookup to User. When the record is submitted, the approval step routes to the user stored in that field. The process definition stays unchanged even if the person in that role changes, because the record determines the approver at runtime.

This is useful when the approver is determined by the business context of the record rather than by the direct manager hierarchy.

Why dynamic routing beats hardcoding

Hardcoded approvers create avoidable maintenance risk:

Someone leaves the company and approvals stop routing correctly.
Admins must update approval definitions every time responsibilities change.
The approval design becomes harder to understand and harder to audit.

Dynamic routing is more resilient:

Changes in reporting lines are picked up automatically when using manager based routing.
Record specific approvers can change without redesigning the approval step.
Processes are easier to maintain over time.

As a rule, prefer manager based or field based approvers wherever possible. Use a named specific user only when the business requirement truly demands it.

Anti-patterns to avoid

As your approval processes become more advanced, a few design mistakes show up again and again.

Monolithic processes with too many conditions

The problem: trying to solve every approval scenario in a single process usually leads to complex entry criteria, overlapping steps, and difficult troubleshooting.

Example of poor design:

Entry criteria with many combined AND / OR conditions
Several steps with similar but slightly different rules
Approvers assigned directly to named individuals

What to do instead: break the design into smaller, focused approval processes where appropriate, or simplify the single process so each step has a clear purpose.

Step names tied to specific people

The problem: naming a step after a person makes the process harder to maintain and understand when roles change.

Poor naming

❌ Sarah Chen Approval
✅ Director Finance Approval

Step names should describe the business role or decision point, not the current person in the seat.

Hardcoded approvers instead of hierarchy or field based routing

The problem: selecting a specific named user for a step means someone must remember to update that step every time the organisation changes.

Poor design

❌ Assign to a named user wherever possible
✅ Use Manager or a supported record driven approver field where the requirement allows it

Default to dynamic routing unless you have a documented exception.

Forgetting to test edge cases

The problem: approval processes often work in happy path testing but fail under real world conditions.

Common failure points include:

A missing manager or unresolved approver
Delegated approval not behaving as expected
Entry criteria that are too broad or too narrow
Field updates or record state changes interacting badly with the approval flow

What to do instead: test with realistic user structures and realistic records. Include missing hierarchy values, delegated approvers, and records from multiple business scenarios. Verify the entire approval outcome, not just whether the submit button works.

👥 User experience: how approvers interact

Approvers are not building the process, they are living in it. The real test of any approval design is whether the people who need to act can do so clearly, quickly, and with enough context to decide.

Salesforce Home: Items to Approve

For many approvers, the first place they see work is Salesforce Home. The Items to Approve component shows a list of pending approval requests with the key actions surfaced: Approve, Reject, and Reassign. Each item typically includes the record name, the submitted date, and a link to the underlying record.

This component is a good place to think about adoption. If approvals are frequent, make sure the approver’s home page is uncluttered and that the Items to Approve component is prominent. If the process is event driven, use a dashboard, list view, or app page to give approvers a single place to check their queue.

Record page approvals in Lightning

The most common approval interaction is on the record page itself. In Lightning, approval quick actions appear in the Highlights Panel or Global Actions when pending. Approvers can open the record, review the fields, related lists, and supporting documents, then click Approve or Reject without switching context.

Good UX here depends on the underlying page layout and Lightning page design. The fields and related lists that matter to the decision should be easy to scan. If approvers need deeper context, add a custom component, Quick Action, or screen flow to surface summary information, help text, or related process guidance.

For example, a discount approval page might include a related list of prior discount requests, a summary of the opportunity amount and margin, and a rich text section explaining the approval policy. The approval quick actions should sit alongside those details so the approver can act confidently.

Email‑based approvals

Salesforce sends templated approval notification emails with a link back to the record and details about the request. Reply-to-approve (keyword based) works for mobile users, allowing approvers to reply with keywords like Approve or Reject.

This is especially useful for mobile or field based approvers who may not want to open the full Salesforce UI. But it also increases the importance of clear email content: include the record name, approval amount, reason for the request, and a visible link to the record. Make sure your email template reinforces the same status values and next steps used in the UI.

Why page design and list views matter

This is where your earlier UX work pays off. Approvers need a consistent, decision focused experience:

Page layouts should surface the right fields and hide irrelevant ones.
Lightning pages should group related information logically so reviewers do not have to hunt for context.
List views and homepage components should make it easy to find pending requests and understand priority.

If the approval request lands in a bad interface, users are more likely to bypass the process, delay decisions, or make mistakes. Good admin design means the approval path is not only correct behind the scenes, but also easy to use in the front-end experience.

🔧 Managing approvals as an admin

Approvals are not a “set it and forget it” feature. Admins need to monitor requests in flight, support stuck work items, and make sure the process is visible and recoverable.

See approvals on the record

The first place to look is the record itself. The Approval History related list shows the current approval status, the approvers involved, the dates of each action, and any comments entered by approvers. For classic approval processes this is usually displayed on the object page layout; for Lightning pages you can also surface it in a dedicated related list or component.

This list is essential for troubleshooting because it tells you:

which step the record is currently waiting on
who approved or rejected earlier steps
whether any comments explain the decision
whether the record is locked and why

If approvers report confusion, the Approval History related list is the first thing to check.

Manage in-flight approval work items

Sometimes approval work items get stuck or need manual intervention. Classic approval work items are visible in list views and in the Items to Approve component, and administrators can reassign or recall requests where the process allows it.

Key admin tasks include:

Reassigning work items when the assigned approver is unavailable or has changed roles.
Recalling submissions when the submitter needs to make a data correction and the process supports recall.
Identifying stalled requests by using list views filtered on age, status, or assigned approver.

Create dedicated list views for support teams, such as “Pending Approvals Older Than 3 Days” or “Approval Requests with No Assigned Approver.” These help you spot process bottlenecks before they become user complaints.

Reporting and audit visibility

Approval processes generate a lot of useful audit data, but it is not always obvious. Start with the standard approval reports that Salesforce provides, then move to more detailed analysis if you need it.

Useful starting points:

Approval History Reports — show who approved or rejected requests and when.
Approval Process Reports — show the number of requests submitted, approved, rejected, or recalled over time.
Work Item Reports — show pending work items, assigned approvers, and age.
Custom Report Types: Create one joining ProcessInstance + ProcessInstanceWorkitem + ProcessInstanceStep for full visibility.

A report built on these objects lets you answer questions like:

Which approvers have the most pending requests?
Which approval processes have the longest cycle times?
How many approvals are being rejected versus approved?

Admins can also use dashboards and email notifications to monitor key process health signals, such as pending approval count, average approval time, and the number of recalled requests.

Support and recovery practices

A few practical admin habits make approvals more reliable:

Document the approval process owner and escalation path so users know who to contact when approvals stall.
Keep approval related email templates and queue membership up to date to avoid notifications or assignments failing.
Review approval history on sample records after deployment to verify the workflow and related actions behaved as expected.

When approvals fail, the fastest recovery is usually to identify the stuck work item, understand whether the approver assignment is wrong or the record is locked, and then either reassign the work item or recall the request as appropriate.

⚡ Flow as the modern approval engine

Salesforce’s strategic direction is clear: Classic remains supported, but Flow is the modern direction for new designs, and Flow Approval Processes are the modern way to build goverened, autible approval workflows. Flow offers a more flexible model for many modern approval scenarios.

What are Flow Approval Processes?

A Flow Approval Process is a declarative orchestration built in Flow that sequences approval work through stages. Each stage contains:

Approval steps — where users or queues act (approve, reject, reassign)
Background steps — where automation runs without user involvement (field updates, subflows, integrations)
Decision elements — conditions that route records to different stages based on data or approver feedback

This structure lets you model complex approval scenarios that would be difficult or impossible in Classic. For example, you could route a contract through a legal review stage, then conditionally send high value contracts to an international compliance stage, while simultaneously triggering background automation to notify stakeholders and update status fields.

The Work Guide component

When an approval process is active in Flow, end users see the Work Guide component on the Lightning record page. This component displays:

The current stage and step within that stage
Buttons and actions available to the approver (Approve, Reject, Reassign, etc.)
Contextual information about the request (submitted date, approver name, step description)
Related information passed from the Flow (reason for the request, supporting data, policy links)

The Work Guide is more intuitive than Classic’s quick actions because it surfaces the entire approval context in one place. Approvers can see where the request is in the workflow and what happens next, making the process transparent and less confusing.

Why choose Flow Approval Processes for new designs?

Several scenarios point toward Flow Approval Processes:

Multi-department or complex routing
If different approvers need to act sequentially or in parallel, Flow’s stage model handles this more naturally than Classic’s limited steps. You can use decision elements to route based on data, approver feedback, or business logic.

Cross object logic
Classic approvals work on a single object. Flow Approval Processes can orchestrate lookups to related objects, check product categories, validate against custom hierarchy fields, and route based on information across your entire data model.

Conditional branching
Suppose a discount approval should route to a regional manager for discounts under $50K, but to the VP Finance for larger discounts. A simple decision element in Flow can branch the approval path. In Classic, you’d need multiple overlapping steps and careful ordering of entry criteria.

Integration with external systems
Flow Approval Processes can call Apex actions, HTTP callouts, or other subflows at any stage. You could notify an external approval system, fetch data from a third-party API, or trigger a Slack message when a high priority approval arrives. This is not as easy to implement in Classic approvals.

Involving internal and external approvers
Some orgs need to gather approvals from people outside Salesforce (partner companies, external consultants, etc.). Flow Approval Processes can support this through custom approval steps and integration patterns.

Richer approval experience
Flow lets you build custom screens, add rich help text, surface related records, and tailor what approvers see based on the record data. The Work Guide component replaces Classic’s simpler quick actions with a more modern, context aware interface.

When to stick with Classic

Classic Approval Processes are not obsolete. They remain the right choice if:

Your approval is simple and linear (one or two approval steps with straightforward criteria).
Your org already has mature, stable Classic processes that work well and don’t need enhancement.
Your team is not comfortable with Flow yet and needs a low friction path to governance.
You need to minimize change risk in a heavily regulated environment.

But for any new approval workflow, Flow Approval Processes should be the default. Salesforce is investing in Flow, Classic remains supported, but Flow is the preferred direction for new designs. For more detail, see Salesforce Help: Automate Your Approvals with Flow Approval Processes.

Automate Your Approvals with Flow Approval Processes The Flow Approval Processes feature streamlines these processes with flow approval processes

➡️ Building a Flow Approval Process

To see how Flow Approval Processes work in practice, we’ll build the same discount approval example from the Classic section, but using Flow. This gives you a direct comparison: the business logic is identical (route opportunities with discounts ≥ 10% to the manager), but the implementation uses Flow’s modern orchestration model.

Flow Approval Processes are built in two main parts: the approval process definition (which defines the overall workflow and entry conditions) and the underlying orchestrated flows (which handle the detailed logic for each stage and step). This separation lets you reuse flows across multiple approval processes and makes the overall design more modular.

Step 1: Create the Flow Approval Process definition

Before you begin, navigate to Setup → Feature Settings → Approval Settings and ensure that Use Flow Approval Processes are enabled in your org.

Navigate to Setup → Flows → New Flow and search for approval processes, you will find two types (as well as some templates):

Autolaunched Flow Approval Process (No Trigger)
Record Triggered Flow Approval Process

Select Record Triggered Flow Approval Process. This creates the high level container for your approval workflow.

Object and entry conditions

Select Opportunity as the object and trigger the orchestration when a record is created or updated. Define entry conditions that match the Classic example:

Field: Discount_Requested__c
Operator: greater than or equal to
Value: 10

These conditions determine when a record is eligible for this approval process. Unlike Classic, Flow Approval Processes can use more complex entry logic if needed, but keep it simple for this example.

Process name and description

Click ‘Save and choose a clear name like Opportunity Discount Approval (Flow) and add a description: “Routes opportunities with requested discounts ≥ 10% to the opportunity owner’s manager for approval using Flow orchestration.”

Record locking and submission control

Unlike Classic Approval Processes, Flow Approval Processes do not have an explicit “Initial Submitter” field in the UI. Instead, submission access is controlled by:

Flow trigger conditions: Who can trigger the record triggered flow that initiates the approval.
Sharing and object permissions: Standard Salesforce security determines who can see and interact with records in approval.
Flow variables and logic: You can add conditional logic within the flow to restrict submission based on user role, record ownership, or custom criteria.

For record locking, decide whether the record should be locked during approval. Set this in the approval stage definition within the flow. When locked, regular users cannot edit the record; admins with Modify All permissions can still edit for recovery. For consistency with the Classic example, enable locking to preserve data integrity during the decision making phase.

Orchestration run fault email

Enter an email address (yours or an admin alias) to receive notifications if the orchestration fails. This is unique to Flow Approval Processes and helps with troubleshooting.

Step 2: Build the orchestrated flows

The approval process definition is the shell; the real logic lives in orchestrated flows. You’ll need to create or reference flows that handle each stage.

For this simple example, create one orchestrated flow that includes:

An approval step for the manager review
Background steps for status updates and notifications

In Flow Builder, create a new Orchestrated Flow (autolaunched). This flow will be triggered when a record enters the approval process.

Entry conditions in the flow

The orchestrated flow is autolaunched by the Flow Approval Process definition. The approval process passes the record context into the orchestrated flow, so you do not add a separate record triggered start element inside the orchestration.

Stage 1: Manager Approval

Add a stage by pressing the add element ’+’ button and selecting Stage.

Enter a label and description.
Set the stage to complete when all steps in the stage are completed.

Then add an Approval Step element:

Label: Manager Review
Description: Manager reviews discount request and approves or rejects.
Condition: When the stage starts, the step starts
Action: Create or pick the action for the user to approve the record e.g. ‘Review Approval Request’.
Approver Type: Manager of the record owner (use the same dynamic routing as Classic).
Actions: Approve, Reject, Reassign (standard options).
Record ID: The Id of Triggerring Opportunity
Lock the record: True
Condition: When the assigned user has completed the action, the step is marked completed

This step pauses the orchestration until the approver acts. If the manager approves, the flow continues to the approval path; if they reject, it branches to rejection handling.

Decision elements for branching

Add a decision element to evaluate the outcome of the Manager Approval step and route the flow accordingly. For example:

If Approved → Run approval background steps.
If Rejected → Run rejection background steps.

Background steps for automation

After the decision, add a stage for background automation that runs without user interaction:

Update Records: Set Approval_Status__c = "Approved" and Discount_Approved__c = TRUE.
Send Email: Notify the sales rep and manager using a templated email.
Call Subflow (optional): Trigger a subflow for follow up tasks, such as creating a finance review task.

For rejection, add a parallel stage with steps:

Update Records: Set Approval_Status__c = "Rejected".
Send Email: Notify the submitter with next steps.
Create Records: Add a follow up task for the sales rep.

This mirrors the step level actions in Classic but gives you more flexibility to add conditional logic.

Step 3: Activate and test

Activate the Flow Approval Process and test thoroughly:

Create a test opportunity with Discount_Requested__c >= 10.
Submit for approval (this can be via a button or auto-submission).
As the manager, use the Work Guide component on the record page to approve or reject.
Verify field updates, emails, and the flow’s audit trail.
Test edge cases: missing manager, rejection path, and orchestration faults.

Deployment considerations for Flow Approval Processes

Flow Approval Processes introduce deployment patterns that differ from Classic:

Versioning flows
Orchestrated flows are versioned like any other flow. When you update a flow used in an active approval process, create a new version and test it in a sandbox. Use change sets or DevOps tools to promote versions between environments.

Activating/deactivating orchestrations
You can activate or deactivate the entire approval process without affecting the underlying flows. This lets you pause approvals during maintenance while keeping the flows available for other uses. Deactivated processes won’t accept new submissions but allow inflight requests to complete.

Orchestration run fault emails
These emails notify you of runtime failures, such as when a subflow errors or an integration callout fails. Include them in your monitoring strategy—set up rules to alert on critical failures and review logs regularly. Unlike Classic’s simpler error handling, Flow gives you detailed fault information to diagnose issues.

Testing in production like environments
Because flows can interact with external systems, test integrations thoroughly. Use sandbox data that mimics production volumes, and verify that fault emails work as expected.

Naming conventions for stages and steps

Mirror the guidance from Classic approvals: name stages and steps after business roles or decision points, not specific people. For example:

✅ Manager Review Stage
❌ Sarah's Approval Step

This keeps your flows maintainable when roles change. Prefix flow names with the approval process for clarity, like Opp_Discount_Approval_Manager_Review_Flow. Document these conventions in your org’s Flow governance guidelines to ensure consistency across teams.

This Flow based discount approval achieves the same outcome as the Classic version but with more extensibility. As your needs grow, you can add parallel stages, cross object lookups, or integrations without rebuilding the entire process.

This example is purposefully simple so you can see the core pattern clearly. Once the basic workflow is working, refine the stage and step design to match your approval policy, automation needs, and user experience.

📊 Classic vs Flow approvals

With two approval engines available, choosing the right one for new work can feel overwhelming. Classic Approval Processes are battle tested and simple, while Flow Approval Processes offer modern flexibility but require more Flow knowledge. This table compares the key aspects to help you decide. Remember, Classic isn’t going away, it is still the right choice for many scenarios but Flow is Salesforce’s strategic direction for complex or evolving needs.

Aspect	Classic Approval Process	Flow Approval Process
Configuration location	Setup → Approval Processes.	Flow Orchestration / Flow Approval Processes UI.
Building blocks	Entry criteria, steps, actions, approvers.	Stages, approval steps, background steps, decision logic.
Complexity sweet spot	Simple to medium, mostly linear approvals.	Medium to high, multi‑team, conditional, cross‑system.
Extensibility	Some; integrate using outbound messages and Apex.	Deep; call subflows, interact with internal and external systems.
Strategic direction	Mature/legacy but still supported.	Salesforce’s modern pattern for advanced approvals.

Key differences explained

Configuration location: Classic lives in Setup, making it accessible to admins without Flow skills. Flow requires Flow Builder, which means your team needs Flow familiarity or training.

Building blocks: Classic uses a step based model with entry criteria and actions. Flow uses stages with approval steps, background automation, and decision elements for branching. This makes Flow more like a full workflow engine.

Complexity sweet spot: If your approval is straightforward (one or two steps, no branching), Classic is faster to build and maintain. For multi-stage processes with conditional routing or integrations, Flow’s orchestration model scales better.

Extensibility: Classic can call Apex or send outbound messages, but it’s limited. Flow can invoke subflows, HTTP callouts, or even orchestrate across objects and systems natively.

Strategic direction: Salesforce invests in Flow, so new features appear there first. Classic is stable but in maintenance mode.

When to choose Classic

Simple, linear processes: One or two approval steps with clear criteria.
Team comfort: Your admins aren’t Flow-savvy yet, and you want quick wins.
Regulatory stability: In highly regulated environments where change is risky.
Existing investment: You have mature Classic processes that work and don’t need enhancement.

When to choose Flow

Complex routing: Multi-team approvals, parallel stages, or conditional branching based on data.
Cross object or integration needs: Lookups to related records, external API calls, or subflow orchestration.
Modern UX: Richer approver experience with the Work Guide component.
Future-proofing: New approval requirements that might involve automation beyond the record itself.

For new approvals, default to Flow unless you have a strong reason to stick with Classic. It gives you more options as your business grows, and the learning curve is worth it for the flexibility.

🎯 Submitting for approval with Flow

Flow gives you two clean ways to get a record into approval:

let the user launch the submission through a button or quick action
let the system submit it automatically when the right conditions are met.

Auto-submit with a record triggered or autolaunched flow

Some approval patterns are best started by the system rather than by a user. When the business rule is clear and the record state is unambiguous, When the business rule is clear, a record triggered flow can automatically invoke the Flow Approval Process when the record meets the criteria.

Typical cases include an opportunity amount over a threshold, a contract moving to Ready for Signature, or a purchase order containing a high risk product line. In those scenarios, the flow is responsible for validating the eligibility logic and then start the approval flow once the record is truly ready.

The most important safeguard in this design is preventing duplicate submissions. A simple status field or checkbox such as Submitted_For_Approval__c is often the way to ensure the flow only starts approval once per record.

Manual submission with an autolaunched Flow

Not every approval should happen automatically. When users need to verify completeness before starting approval, a lightweight autolaunched flow can still provide a controlled one-click experience.

The flow receives the current record, confirms it meets the approval entry conditions, and then submits it into the appropriate approval process. Exposing that flow through a Lightning quick action or a dedicated button keeps the interface simple while centralising the submission logic and any error handling.

That approach is useful when the business wants approval to be explicit, but still wants the benefits of Flow based validation and status updates. If the record is already in approval, missing required data, or lacks a resolvable approver, the flow can return a concise message instead of letting the user continue blindly.

Comparing auto-submit and explicit submission

Choosing between automatic and user invoked submission is more than a technical decision. It reflects how much control the business wants in the user’s hands, how visible the approval transition should be, and whether the process should start as soon as a record reaches a defined state.

Submission style	Best fit	Control point	User experience
Auto-submit	Records that should enter approval automatically once they are eligible, such as high-value transactions or compliance triggered cases	System-driven by business rules	Lightweight for users, but requires clear messaging so people understand why approval started without a click
Explicit submit	Records that need a deliberate readiness check, draft work, or a user confirmation before approval begins	User driven via a button or quick action	More visible and intentional, useful when review must happen before the process starts
Hybrid	Portfolios with both routine work and special case approvals	Combination of system and user triggers	Balances automation with control, using auto-submit for exceptions and manual submit for ordinary cases

Many organisations settle on a hybrid approach: explicit submission for the normal case, and auto-submit for high value or regulated scenarios where the record should not linger outside approval.

💻 Developer corner: Apex and programmatic approvals

For developers, it is important to understand how approvals can be driven outside the standard UI. Apex provides the Approval class and its Approval.process method to submit, approve, reject, or recall approval work programmatically.

At a high level, the Apex approval pattern looks like this:

Query the record(s) and confirm they meet the approval process entry criteria.
Create an Approval.ProcessSubmitRequest or Approval.ProcessWorkitemRequest.
Call Approval.process() and inspect the returned Approval.ProcessResult.

This is especially useful for:

Bulk submission jobs: a nightly Apex batch or scheduled job can find records that became eligible during the day, submit them in bulk, and write audit fields such as Approval_Status__c or Submitted_For_Approval__c.
Custom UI wrappers: a Lightning Web Component can call Apex to submit a record for approval, then refresh the page or show a custom toast if submission fails because of missing criteria or a locked record.
Integration triggered approvals: external systems can call Apex REST endpoints, which in turn call Approval.process() to start or act on approvals based on incoming data from ERP, procurement, or partner portals.

Apex is not only for submission. You can also use Approval.process() with Approval.ProcessWorkitemRequest to programmatically approve or reject a work item, which is useful when integrating with non-Salesforce decision engines or building a custom review experience.

Testing is critical. In unit tests, create records that clearly meet the same criteria used by the approval process, then assert that:

the record was successfully submitted or approved,
the expected ProcessInstance / ProcessInstanceWorkitem records were created,
any custom status fields or follow up updates were applied.

This developer corner is intentionally light on code. The Approval.process() method and supporting request/result classes give you everything you need for production grade programmatic approvals. Full implementation examples are available in the Salesforce Developer Guide and Trailhead, but the key takeaway is that Apex can bridge Salesforce automation and external systems while preserving the audit trail and governance of standard approval flows.

For additional developer reading, see Salesforce’s Apex documentation on approval processing

Apex documentation on approval processing An approval process automates how records are approved in Salesforce.

⚠️ Limits, quirks, and gotchas

Approval processes can look simple on the surface, but a few platform quirks can turn a stable design into a fragile one. Admins should treat these behaviors as part of the design checklist, not as afterthoughts.

Platform and permissions constraints

Approval processes work on most standard and custom objects, but some objects are excluded. For the exact supported object list and edition requirements refer to the Salesforce help topics for About Flow Approval Processes and the Classic approval limits documentation.

Key permission notes:

Users must have the right to edit the record and the object, plus the approval process must allow them to submit. For Classic approval processes, the submitter options are explicit in the process definition.
Approvers must also have access to the record and object, and delegated approvers must be enabled if you rely on delegation.
When “Administrators only” record locking is enabled, regular users cannot edit the record while it’s pending approval. Admins with Modify All permissions can still edit for recovery. This protects inflight records while giving admins an escape hatch.

Record locking and concurrent automation

Record locking is a common source of surprises. When a record enters approval and is locked, Salesforce prevents UI edits by normal users, but system-level automation such as Apex or admin-level updates can still modify it in some cases.

What to keep in mind:

Locked records can still be updated by automation that runs in system context, including Apex and some Flow actions. That means a locked approval record can still change if your automation pipeline is not designed carefully.
If your org has record triggered Flows, workflow rules, or process builders that fire on the same object, they may behave differently when the record is locked. The approval process can block user edits, but not always block backend automation, so test the full automation chain.
The “Administrators only” edit setting is not a substitute for good design. It is useful for recovery, but changes by admins while approval is pending may still cause the request to behave unexpectedly if later steps depend on the original field values.

Mid-process criteria changes

Approval processes evaluate step criteria when each step is reached, not only at initial submission. That means record data can change while a request is pending, and those changes can affect later steps.

A common gotcha is if a record no longer meets the criteria for a later approval step when that step is evaluated, Salesforce may skip the step or fail the process depending on the process design. This can look like an unexpected path or a stalled approval.

For classic approval processes, that behavior is especially important in multi-step designs. If you allow key routing fields to change while a request is pending, you may end up with no matching step later in the process.

Auto-rejection when no next step applies

A closely related issue is auto-rejection. In classical approval logic, if a record reaches the next approval point and none of the remaining steps match, the process can auto-reject the request rather than advance it.

Common cause: Record changes while pending (routing field updated), so it no longer fits any step criteria.

To avoid this, keep step criteria stable for the lifetime of the request, or use locking and validation logic to prevent the fields that determine routing from changing after submission.

Upstream automation interactions

Approval processes do not run in isolation. Upstream automation such as record triggered Flows, Apex triggers, or integrations can be blocked, delayed, or rerouted by approval behavior.

Practical examples:

A field update made by a record triggered Flow may fail if the record is locked, or it may execute after the approval process completes and cause a second save.
Apex code that submits a record for approval should check the current approval status and lock state before calling Approval.process(), to avoid duplicate submissions or partial failures.
If field updates in approval actions change values that are also watched by other automation, you can create unexpected loops or save conflicts.

The best practice is to document which fields are part of approval routing or status, and protect them with explicit automation guards and test cases.

📦 Testing, deployment, and lifecycle

Approval processes should be treated like any other governed change: they need repeatable tests, reliable deployment, and a clear retirement plan.

Testing approval behavior

Start in a sandbox and cover every approval outcome, not just the happy path. That means verifying:

Approve and reject paths for every step or stage.
Recall and reassign behavior where the process allows it.
Edge cases such as missing approvers, delegated approvers, and records that do not meet later step criteria.
Related automation such as field updates, email notifications, and follow up tasks.
Locking and edit behavior to confirm users and automation behave as expected when a record is pending approval.

Use real-ish users, roles, queues, and templates in sandbox testing. If your approval process depends on a manager hierarchy, test with users who have managers and with users who do not.

Deployment strategies

Approval processes are configuration, but they rarely stand alone. Treat them like any other governed change and move them through your release pipeline with their dependencies, not as isolated tweaks. For Classic Approval Processes, that usually means deploying the process definition together with its supporting pieces: email templates, queues, approval page layouts, and any custom fields the process relies on. For Flow Approval Processes, you’re deploying the approval definition plus the orchestrated flows, subflows, and any referenced resources such as email alerts, Apex actions, or custom metadata.

In every case, make sure the target environment already has the right shape: queues, roles, approval specific fields, and templates must exist and be consistent, otherwise the process may deploy but behave differently. Use whatever DevOps tooling your org has standardised on—change sets, DevOps Center, source driven deployments—but package the approval process and its dependencies as a single change, not scattered pieces.

Lifecycle and migration planning

Approval processes may not be permanent fixtures. Plan for how they will evolve, be replaced, or be retired safely.

When migrating from Classic to Flow, keep the existing process running for current inflight requests while you deploy the new Flow-based equivalent.
Pause new submissions during the migration window if needed by deactivating the old process and enabling the new one in a controlled window.
Document the process owner, the technical owner, and the retirement criteria so future admins know when and why the process can be changed.
Review approval usage periodically. If a process is no longer used, disable it rather than leave it active.

Good testing, disciplined deployment, and active lifecycle management turn approval processes from brittle configurations into dependable controls.

⚖️ Governance, documentation, and naming

Approvals are controls, not just automation. That means they deserve the same governance you apply to integrations, sharing rules, and other high‑impact changes. A well‑designed approval that nobody can understand or safely change is still a risk.

Document every approval, not just the configuration

A good rule of thumb is that every approval process should have a one‑page description that a non‑technical stakeholder can read and understand. At minimum, capture:

The purpose in plain language: what business decision this process supports.
The object and scope: which records qualify and which do not.
The entry conditions: the exact criteria that decide when a record can be submitted.
The stages or steps: who reviews what, in what order, and what each step is checking.
The approver sources: manager hierarchy, queues, specific roles, or user lookups.
The related fields and actions: status fields, flags like Submitted_For_Approval__c, and any field updates, tasks, or notifications that run on submit, approval, rejection, or recall.
The SLAs and expectations: how quickly approvals should be actioned and what happens if they are not.

It is also worth documenting how submission works: whether the process is auto‑submitted by Flow, started by a button, or initiated from an external system. Make it clear which field(s) indicate that a record has entered approval so admins and auditors can see the state at a glance.

You do not need a heavy template tool for this. A simple page in your Confluence/Jira/Notion space, or a standard section in your architecture decision records, is enough as long as it is consistent.

Business owners, technical owners, and change paths

Every approval should have two named owners:

A business owner who is accountable for the rules, the routing, and the outcomes.
A technical owner (often an admin or developer) who is accountable for the implementation details.

Include both in the documentation and, where possible, in the process description or a custom metadata record. That way, when requirements change or issues emerge, people know exactly who to involve. It also discourages ad‑hoc tweaks in production, because there is a visible path for change.

As part of governance, agree the conditions under which an approval process can be changed or retired: for example, a change in policy, a migration from Classic to Flow, or a new regulatory requirement. Capture those retirement criteria alongside the owners so future admins are not guessing.

Naming conventions that survive turnover

Naming is where a lot of approval complexity hides. If step names and email templates reference specific people, they age badly. If they reference roles and business functions, they remain meaningful when people move on.

Favour patterns like:

Opportunity - Discount Approval - North Region
Contract - Legal & Finance Approval
Case - Clinical Review - High Risk

over names like John Smith Discount Approval. The same principle applies to:

Approval process names: describe object and purpose.
Step names: describe the decision, not the person (for example, “Director Finance Approval” rather than “Sarah Chen Approval”).
Email templates: include the object and purpose, such as Opp_Discount_Approval_Assignment.
Queues and groups: name them by function (for example, Discount Approval Managers) rather than team nicknames.
Flows: when a Flow or autolaunched Flow is part of approval submission or routing, use names that tie it clearly to the approval, such as Opp_Discount_Submit_For_Approval.

Consistent naming makes it much easier to answer simple but important questions later: “Which approvals touch Opportunity discounts?” or “Where are all the legal approvals configured?”

Capturing submission style and routing fields

Finally, treat submission style and routing fields as first‑class governance concerns. In your documentation, explicitly note whether the process uses:

User‑driven submission (buttons, quick actions, screen flows).
System‑driven submission (record‑triggered Flows, Apex, integrations).
Or a hybrid of both.

Record which fields determine routing and status, and call out any fields that must not change while a request is in progress. Those are the fields you will later protect with validation rules, Flow guards, or Apex checks.

A little discipline here goes a long way. When each approval is documented, owned, consistently named, and explicit about how it starts and routes, it stops being a mysterious black box and becomes a predictable, governable part of your platform.

Final thoughts

Use this guide as the foundation for approval work that is built to last: governed, testable, and easy to evolve as your org and business rules change. Keep your approval processes under review, because requirements, ownership, and integrations evolve faster than the underlying object model. Build in regular checkpoints for validation, reporting, and end user feedback so your approval paths remain reliable, transparent, and aligned with the business.

Next steps

Approval emails are often the first place a process meets your users, which makes them as important to design well as the approvals themselves. In Part 5 — Email Templates & Deliverability, you’ll learn how to build maintainable templates, manage merge fields, and keep your org’s email reliable, secure, and trusted by recipients.

Resources

Approve Records with Approval Processes Ensure that critical records are reviewed by the right people at the right time.

Create Approval Processes An approval process automates how records are approved. You can create an approval process for a task, email alert, field update, or outbound message.

Build a Discount Approval Process Make it easy for your sales reps to get the approvals they need for discount offers.

Superbadge: Approval Process Management Demonstrate your ability to automate and enhance approval processes.

Superbadge: Approval Process Troubleshooting Use your approval process troubleshooting skills to increase productivity.

Automate Your Approvals with Flow Approval Processes The Flow Approval Processes feature streamlines these processes with flow approval processes

Apex documentation on approval processing An approval process automates how records are approved in Salesforce.

Mastering Salesforce Administration: Part 4 - Approval Process

✅ Adding a governance layer with Approval Processes

🔎 Conceptual overview

🛤️ Approvals in the automation landscape

Distinction from other automation

Enforcement and practical notes

🔄 Classic vs Flow vs Custom Approaches

🧩 Core approval concepts and terminology

The approval lifecycle

The sequential decision points

Approvers and delegated approvers

Actions and outcomes

Approval request / work item

Putting it all together

📐 Designing the process before you build

Map the business process end to end

Work through the official design considerations

Document your design with these artifacts

Why this design work saves time later

✍️ Classic Approval Processes: overview and components

📋 Classic Approval Processes: step-by-step build

Step 1: Create the Approval Process definition

Process name and description

Entry criteria

Initial submitter

Record editability

Next Automated Approver

Initial submission actions

Step 2: Add approval steps

Step name and description

Step entry criteria

Approval step assignment

Multiple approvers in this step

Assign the step to multiple approvers

Step 3: Add workflow actions

Initial submission actions

Step approval actions

Step rejection actions

Step 4: Configure final approval/rejection actions

Final approval actions

Final rejection actions

Step 5: Activate and test

Key practices for building Classic Approval Processes

🔄 Classic approvals: advanced step patterns

Multi-step approvals with narrow vs broad ordering

Narrow-to-broad ordering: specific criteria first

Broad-to-narrow ordering: general review first, then conditional review

Multiple approval processes on the same object

When to use multiple processes

How Salesforce evaluates multiple processes

Advantages of multiple processes over one monolithic process

Multiple approvers in a single step

First response decides vs all must approve

Example: first response from an approval queue

Considerations and tradeoffs

Dynamic approvers: following roles and relationships instead of hardcoding people

Manager hierarchy: the standard pattern

Field based approvers: routing from related users

Why dynamic routing beats hardcoding

Anti-patterns to avoid

Monolithic processes with too many conditions

Step names tied to specific people

Hardcoded approvers instead of hierarchy or field based routing

Forgetting to test edge cases

👥 User experience: how approvers interact

Salesforce Home: Items to Approve

Record page approvals in Lightning

Email‑based approvals

Why page design and list views matter

🔧 Managing approvals as an admin

See approvals on the record

Manage in-flight approval work items

Reporting and audit visibility

Support and recovery practices

⚡ Flow as the modern approval engine

What are Flow Approval Processes?

The Work Guide component

Why choose Flow Approval Processes for new designs?

When to stick with Classic

➡️ Building a Flow Approval Process