How to Build an Approval Process in Salesforce — The Right Way

I still remember the afternoon a single stuck request blocked a whole launch. I watched teammates hunt for the missing approver and felt the drag of brittle routing and scattered notifications.

That moment pushed me to rethink how I design sign-offs. When Flow added Approval Orchestration in Spring ’25, I moved key work into stages and steps so decisions happen on-screen and background updates run reliably.

In this short intro, I’ll set expectations: the object I target, the record lifecycle I touch, the steps and criteria I wire, and how the approver gets the request without manual routing.

Later I’ll show the page-level experience with the Orchestration Work Guide and Approval Trace, plus lists and fields I surface so users and admins can audit easily.

Key Takeaways

• I explain why I moved from classic sign-offs to Flow orchestration after Spring ’25.
• You’ll see how stages, screen steps, and background steps work together.
• I define the record, the approver source, and exact criteria up front.
• Page components and lists make the request visible and easy to audit.
• I map submission, final approval, and rejection to clear field updates and notifications.

What I Mean by “The Right Way” for Approvals Today

I learned to pick the right routing engine the hard way—after a stuck sign-off delayed a launch. My rule now is simple: choose the tool that fits the record volume, complexity, and human choices required.

Classic approval processes route records through defined steps with entry criteria, approvers, and actions like email alerts, field updates, tasks, and outbound messages. Records lock on submission by default, and classic supports first-response versus unanimous options, delegated approvers, queues, and manual next-approver selection.

Flow Approval Orchestration (Spring ’25) introduced stages, interactive Approval Steps that can use screen flows, and Background Steps that run autolaunched flows. You can set stage completion logic, use Evaluation Flow checks, and route with Decision elements. Summer ’25 added recall paths and Fault Paths for resilience; Winter ’26 brought a debug mode with manual output variables.

I still pick the standard tool when manual selection of the next approver or delegated approver behavior is required. For everything else, orchestration wins for interactive steps, bundled background actions, and clearer stage logic.

salesforce approval process guide: What You’ll Build and Why It Matters

A stalled launch taught me to make requests obvious and routing reliable.

User intent, scope, and outcomes I’m targeting

I build a guided, Flow-based process on the Opportunity object that captures a clear decision, updates a record, and notifies the right user at the right time.

Practical pattern: trigger on Opportunity creation when the related Account Type equals Customer. The Opportunity Owner’s manager is the approver.

My minimal steps: a screen flow captures the decision and a small autolaunched flow updates Approval_Status__c and sends notifications. I use the Evaluate Approval Requests screen template and store approver as username in the user resource.

I add concise fields for decision, timestamp, and context so analytics and audits are easy. I name notification templates clearly and test end-to-end with one record first to validate each action and expected outcome.

Desired outcomes: faster cycle time from submission to decision, fewer questions, and traceable approvals on the page.

Plan First: Criteria, Approvers, Objects, and Fields I Define Upfront

I begin every build by writing plain-English rules that decide which records qualify for review. This makes the entry logic testable and avoids late surprises.

Entry criteria and field readiness across the target object

I document criteria in plain English, then translate them into conditions or a formula. I note edge cases so a record either clearly qualifies or it does not.

I inventory the fields I need on the object and mark which field values must be populated before submission. I also list the fields autotasks will set during the run.

Who can submit, who approves, and how many approval steps

I lock down the initial submitters up front and define the approver source: manager, queue, or a user resource that holds a username. I keep steps minimal and give each step a clear name and description tied to business rules, not people.

Record locking, editability, and page layout visibility

I decide when records lock and who can edit during the run. Classic flows lock on submission by default, with admin edits configurable; Flow steps can also lock and allow approver edits.

I design the page layout so approvers see only the critical fields and expose the approval history or work items as a related list for auditability. Finally, I map the actions on submit, final approval, and rejection so outcomes stay deterministic.

Choose the Right Engine: Approval Process or Flow Approval Orchestration

I decide the engine by asking when and how the object should trigger the run.

Autolaunched vs. Record-Triggered Orchestrations

I pick Autolaunched orchestration when a button press or another automation should start the flow. It is handy for manual starts, bulk runs, or when a screen is not required.

I choose Record-Triggered orchestration when a create or update must immediately move a record into the run. That keeps entry predictable and reduces manual steps.

Stages, Approval Steps, and Background Steps

Stages group related work. An Approval Step runs a screen flow for interactive decisions. A Background Step uses an autolaunched flow for updates and notifications without user input.

I place UI actions in Approval Steps and data actions in Background Steps to keep maintenance simple.

Evaluation Flow, Decisions, and Completion Logic

I use Evaluation Flows and IsOrchestrationConditionMet to gate complex criteria between stages. Decision elements route records cleanly so no single step becomes spaghetti logic.

For completion, I tune whether all steps must finish or if conditional rules mark a stage done. I also decide per step whether to lock the record or allow approver edits.

Define Approval Steps and Routing Logic the Smart Way

I start by mapping who must act and why, then I translate that into clear step logic.

I map approver sources to fit the org: a manager field for simple hierarchies, queues or groups for coverage, and named users when a role is fixed.

For multi-approver work, I pick first response when speed matters and unanimous when risk is high. That choice changes how a step completes and who can move a record forward.

Routing nuances and criteria

I keep each step’s criteria narrow and explicit. If a condition fails, the else path is clear: go to the next step, mark as approved, or trigger rejection. That prevents stalls.

Escalation, fallback, and edits

I design fallback paths for out-of-office approvers and add escalation rules that hand work to a queue or alternate approver. I name steps by logic, not people, so reorgs don’t break routing.

Where needed, I lock the record but allow approver edits to fix small data issues. In orchestration the approver must be set inside the step, so I pass usernames as user resources to keep routing reliable.

Configure Actions: Initial Submission, Final Approval, Final Rejection, and Recall

My first job is to decide what must happen the moment someone hits submit. I keep the list short so the run stays predictable and easy to test.

Initial submission actions include the automatic lock, a quick email to the approver, and a field update that stamps the submitted state. I prefer minimal submission actions so the approver sees the right context and the record stays immutable until a decision.

Final approval actions

I script final approval actions to run downstream updates. Autolaunched flows set status fields and timestamps, then send notifications to the submitter and stakeholders.

Final rejection actions

For rejection I run controlled rollbacks: field updates restore safe values and a clear email explains next steps. I test rejection actions end-to-end so there’s no ambiguity.

Recall actions and when I add them

After Summer ’25 I add recall paths at the start node when needed. Recall runs in background steps to restore fields, unlock or keep the record locked per policy, and notify participants.

Tip: I decide whether emails and field updates live in classic actions or inside autolaunched flows. Bundling them in background flows makes reuse and testing easier.

Notifications, Templates, and the UI: Work Guide, Approval Trace, and Email

Good messages and a tidy page reduce friction. I send concise assignment and submitter emails that state the decision needed, a clear next step, and an SLA. Approvers can reply with keywords to take action, so quick decisions happen even without opening the record.

Custom email templates let me brand messages and include contextual fields like record name, current stage, and related fields. I keep the body short, add one action link, and include fallback instructions if the approver is out of office.

Orchestration Work Guide on the record page

I add the Orchestration Work Guide component to the page so approvers see work items in context. It lists active tasks and the actions they can take.

I configure it to auto-hide when empty, which keeps the page clean for everyday work.

Approval Trace and bulk visibility

I place Approval Trace on the page to surface work items, status, comments, assigned to, and reviewed by at a glance. That removes the need to hunt through related lists for history.

For managers and admins, I use the Approvals Lightning App list views to monitor submissions and work items in bulk. From those lists I can reassign items or open a row to review details without extra clicks.

Consistency matters: I name templates and component labels the same across the UI and show only the fields needed to decide. That reduces noise and builds trust in the information presented.

Build the Orchestration: A Practical Walkthrough I Use

My practical rule is to capture the approver’s choice on-screen and push all updates into a separate autolaunched flow. I begin by mapping a short screen flow for the decision using the Evaluate Approval Requests template. That gives me the UI elements and comments I need without starting from scratch.

I then create an autolaunched flow that performs the field update to Approval_Status__c and sends notifications. Keeping updates modular makes reuse simple and reduces risk when I change emails or timestamps.

Typical stage design: start with an interactive step that runs the screen flow, then add a Background Step that runs the autolaunched flow. I pass variables cleanly and use a user resource that stores the approver’s username for routing.

I decide whether steps run sequentially or in parallel based on throughput and review needs. Decision elements route the record to the correct next stage. When nuance is required, I gate completion with an Evaluation Flow and IsOrchestrationConditionMet so the stage waits until criteria met.

I always test a full submission with one record, confirm the Orchestration Work Guide shows the work, and verify each field update reflects the final state without timing issues.

Quality, Safety, and Scale: Fault Paths, Debug, and Permissions

I make fault handling a design point, not an afterthought, so runs stay predictable at scale. Summer ’25 added stage-level Fault Paths to Flow orchestration, and I now treat them as required safety valves.

Fault Paths and safe outcomes. I add a Fault Path to each stage so an error routes to a clear fallback or a notification step. That protects data and user trust at higher volumes and avoids noisy retries.

Debug and rollback testing. Winter ’26 gives a Debug tab where I set manual output variables to simulate async steps. I debug in rollback mode so the underlying records remain untouched while I validate actions and timing.

Permissions and activation guardrails. I grant Approval Designer sparingly for autolaunched flows and use Submit for Activation to route changes to an approver. That adds an internal review step and allows recall when activation needs to be halted.

I also watch org limits—up to 50 versions—and monitor separate failure emails for orchestration versus the specific flow. Finally, I tune page components and list filters so the manager and user views stay responsive as records scale.

Testing, Reporting, and Evolving the Process Over Time

I run a tight sandbox regimen so every branch behaves the same in production. I enumerate scenarios that hit every route, including edge cases for validation rules and CRED checks. I confirm submission actions fire at the right moment and that page components show the expected columns.

Operational checks: I use the Approvals Lightning App list views for Approval Submissions, Work Items, and Submission Details. From those lists I reassign work items and review throughput to validate real-world load.

I build custom report types to slice data beyond list views. Reports let me monitor trends, bottlenecks, and who frequently returns a request for edits.

For classic flows I clone when steps change and respect activation limits. For flows I keep names consistent and manage versions under org caps. I bundle email template updates, flows, and page tweaks into deployment plans so nothing breaks on release.

I document lessons learned, update the quick reference with approver names and escalation paths, and iterate so the processes evolve with the business.

Conclusion

I wrap up with the practical checklist I use when I build and iterate approval flows. Choose the right engine—classic for manual next‑approver choices, orchestration for staged, interactive runs that support recall, fault paths, and debug.

Keep outcomes predictable: define clear approval steps, attach initial submission actions, final approval actions, and final rejection actions. Anchor the run with a field update and crisp email template so status is obvious.

Make the page and list views actionable so approvers and users find requests fast. Protect quality with fault paths, debug tests, and tight permissions. Pilot on one object, learn from users, then scale.

Author Bio

Gobinath

My Profile | + Recent Posts

Co-Founder & CMO at Merfantz Technologies Pvt Ltd | Marketing Manager for FieldAx Field Service Software | Salesforce All-Star Ranger and Community Contributor | Salesforce Content Creation for Knowledge Sharing

• 

  March 30, 2026

  Salesforce Errors You Should Never Ignore
• 

  March 24, 2026

  Salesforce Integration With Payment Gateways (Stripe, Razorpay, PayPal)
• 

  March 17, 2026

  When Should You Hire a Salesforce Consultant?
• 

  March 10, 2026

  7 Salesforce Customizations That Save Time for SMEs