Salesforce Approval Processes in Flow: Approval Orchestration Step by Step

Approvals decide how fast a deal closes, a discount ships, or a purchase clears finance. Many Salesforce teams still run them on classic approval processes, built years ago and edited by whoever had time. Building Salesforce approval processes in Flow gives you stages, parallel steps, background actions, and approval data you can report on. It also gives you more to design, test, and maintain than the classic tool did.

In this guide, we explain how Flow approval orchestration works and when it beats a classic approval. We then build one step by step, from planning to testing. You will learn how to assign approvers, handle recall and record locking, report on results, and avoid the gaps that surprise teams after launch. Each section gives you a decision or a checklist you can use on your own approvals.

TL;DR

Approvals Now Run as Flow Orchestrations

Flow approval processes are built on Flow Orchestrator. An orchestration holds stages and steps, approvers receive work items, and background steps update records. Existing classic approvals keep running, so you choose which ones to rebuild instead of facing a forced switch.

Plan Approvers and Outcomes Before Building

Most approval problems start before Flow Builder opens. Map the sequence, the approvers, the possible outcomes, and the flows each step needs. Build and activate those flows first, then assemble the orchestration around them and test every path in a sandbox.

Rebuild Where It Pays Off, Then Govern

Consider rebuilding approvals when routing, visibility, or maintenance needs exceed what the current design can provide. Check existing reporting options before treating reporting alone as a reason to migrate, and retain processes that already meet business requirements. After launch, review failed orchestrations, check approver permissions, and keep one named owner for every approval so the process stays reliable as people and rules change.

Why Flow Approvals Are Replacing Classic Approval Processes

A classic approval process is one configuration on one object, with entry criteria, ordered steps, and actions. A Flow approval is an orchestration built in Flow Builder from stages and steps. Practitioner write-ups date the feature to Spring ’25, with later releases adding recall, debugging, and an Approvals app. Confirm the current feature set in Salesforce Help’s Flow Approval Processes article, because the capabilities have changed quickly.

The reasons teams switch are practical: flow approvals can run steps in parallel, call background flows, and route by Decision elements, and they write to approval objects that reports can read. Classic approvals keep working, and no source we reviewed gives a retirement date, so switching is a choice. Treat each approval as a candidate, then rebuild the ones where the gains are clear. Approvals that touch revenue, spend, or customer commitments usually deserve the first look, because delays there cost the most. Start by listing every active approval, who submits it, and how often it runs. If you are still comparing tools for a job, our guide to Agentforce, Flow, and Apex shows where each one fits.

How Approval Orchestration Is Built

Flow approvals sit on Flow Orchestrator, so the building blocks come from there. Salesforce’s Trailhead module on Orchestrator describes the three core pieces as stages, steps, and flows. Understanding each one makes the rest of the build easier, because every design choice maps back to them.

Orchestration Types

Choose a dedicated Flow Approval Process type according to how the request should start. Use a Record-Triggered Flow Approval Process when a record creation or update should start approval automatically after the entry criteria are met. Use an Autolaunched Flow Approval Process when a user or another automation should decide when to submit. Salesforce also documents an External System Change-Triggered Flow Approval Process for supported external events through MuleSoft, which requires the relevant add-on.

Stages and Steps

A stage groups related steps into a phase. Salesforce says stages run sequentially and only one stage can be in progress at a time. Steps inside a stage can run sequentially or at the same time. Each stage has completion conditions you configure. Use stages to mirror the real phases of your approval, such as manager review, then finance review, then legal review.

Interactive and Background Steps

Approval steps create work items for assigned approvers and reference an active screen flow. Approvers can approve or reject through supported interfaces without always running that flow. Background steps run an active autolaunched flow to perform work such as updating records or sending notifications. Evaluation flows can provide more complex conditions for starting or completing steps.

Deciding Whether to Rebuild a Classic Approval

Not every classic approval needs a rebuild. One practitioner write-up reports that no migration tool exists for approvals, so each rebuild is manual work. Salesforce’s documentation is the place to confirm that for your release. Weigh the effort against what you gain, and use the table below to decide.

Run old and new approvals side by side in a sandbox before any cutover. Keep the classic version available until the new one has handled real requests without incident.

Plan the Approval Before You Open Flow Builder

Salesforce’s module on identifying steps and building flows recommends planning the supporting flows early. You can create a draft Flow Approval Process before every dependency is complete, but its required flows and configuration must be ready before activation. Map the approval screens, background actions, inputs, and outputs first so missing dependencies do not delay testing or deployment.

Start with five questions:

• Sequence: Which reviews happen in which order, and which can happen at the same time?
• Approvers: Who approves each step, and do they come from a user, a group, or a queue?
• Outcomes: Which outcomes exist, such as approve, reject, or send back for changes?
• Side effects: What should happen on approval and on rejection, such as a status change, a task, or a notification?
• Exceptions: What happens when an approver is on leave, when the record changes mid-approval, or when a submitter cancels?

List the flows each approval step and background step will reference. Approval steps require an active screen flow with the required decision output, while background steps use active autolaunched flows. Reuse a flow when its inputs, outputs, and behavior suit each caller. Define any business outcomes beyond approval and rejection separately, including the status changes, notifications, and resubmission rules they require.

A Worked Example: Discount Approval on an Opportunity

Consider a sales team that needs manager approval when a rep requests a discount above a limit set by finance. After the manager approves, finance reviews the request. This is an example, not data from a real org, and it uses no real figures. The steps below show one way to build it.

Step 1: Map the Approval

Write down the stages: manager review, then finance review. Mark where the request starts, which field triggers it, and who owns the process. Note the approvers, the record fields involved, and the status values the record should show at each point, such as Pending, Approved, and Rejected. Confirm the discount limit with finance and store it where your criteria can read it. Agree on what a rejection means for the opportunity, since that decides the background actions.

Step 2: Build the Approver Screen Flow

Create a screen flow that presents the request and captures the approver’s decision. Add a Text variable named approvalDecision, make it available for output, and return either Approve or Reject. This output is required by the approval step. To capture comments, add an optional Text output variable named approvalComments. Test both decision values and activate the screen flow before activating the approval process.Keep the screen focused on the information needed for the review. Approvers can complete work items through supported interfaces without running the associated screen flow. 

Step 3: Build the Background Flows

Create autolaunched flows for the work no one should do by hand. One sets the approval status field on the opportunity, another creates a task for the account owner, and another notifies finance. Pass the record ID and the outcome in as variables. Give each flow a clear description, as Trailhead recommends, and activate them.

Step 4: Assemble the Orchestration

From Setup, open Flows, select New Flow, and choose Record-Triggered Flow Approval Process. Configure Opportunity as the triggering object and define entry conditions for the discount request. Include conditions that prevent routine edits from creating duplicate submissions while a request is already pending.Add a manager review stage containing an Approval Step that references the active screen flow and its assigned approver. After that stage, use a Decision element to check the approvalDecision output. Route an approval to finance review and a rejection to a stage containing the rejection actions.

Step 5: Add the Components to the Record Page

Approvers complete their work in the Flow Orchestration Work Guide, a screen component you add to the record page in App Builder. Practitioners also describe an Approval Trace component for history. Add both to the opportunity page layout, then check that each approver profile can see them.

Step 6: Test, Activate, and Train

Test every path in a sandbox, including approval, rejection, recall, unavailable reviewers, and failures before any approval is completed. Include realistic record batches and verify final submission statuses, notifications, and record locks. Deploy the approval process and its dependencies to the target environment, validate permissions and configuration, and activate the required associated flows before activating the approval process. Coordinate the submission cutover and train users before accepting live requests. Monitor the first week closely for failed submissions, duplicate actions, and stalled reviews.

Assigning Approvers: Users, Groups and Queues

Approval steps support assignments to users, public groups, queues, or resources that determine the assignee at run time. Choose the pattern according to the review policy and the coverage needed when someone is unavailable.

• A named user: Assign a specific reviewer when one person owns the decision. Confirm access and plan delegate coverage.
• A public group: Decide whether one response is sufficient or unanimous approval is required. With unanimous approval, all members must approve, while one rejection rejects the step.
• A queue: Configure queue assignment for the approval work item. Do not infer its availability solely from whether the underlying business record can be owned by a queue.
• A dynamic resource: Supply the username, public group API name, or queue API name expected by the assignment configuration.

For supported autolaunched approval processes, the Request Approvals component can let a submitter choose an approver. Assign the relevant approval steps to the firstApprover resource and configure the component to require that selection. This is a specific submission configuration, rather than a general ability to choose every subsequent approver.Test assignments with representative user permissions, delegates, group membership, and unavailable reviewers. Also test reassignment restrictions: work items from steps requiring unanimous approval cannot be reassigned in the same way as ordinary work items.

Choosing Approval Logic: Sequential, Parallel and Conditional

Approval logic decides how a request travels. Three patterns cover most needs, and an orchestration can combine them. Pick the simplest pattern that matches the real policy, because every extra branch adds a test case and a possible stall.

• Sequential: Each stage waits for the one before it. Use this when a later reviewer needs the earlier decision, such as manager review before finance.
• Parallel: Steps inside one stage run at the same time. Use this when reviews are independent, such as legal and security checking the same request.
• Conditional: A Decision element sends the request down a path based on record values, such as skipping finance for small requests.
• Custom completion: An evaluation flow can check more complex completion conditions, but it does not automatically collect independent votes. For a rule such as two of three reviewers agreeing, define how each decision is recorded, how the threshold is calculated, and what happens to outstanding work items when the threshold is reached.

Write the policy in plain language first, then translate it into stages and steps. A sentence like “finance reviews every request above the limit, and legal reviews only contracts with custom terms” converts directly into a stage, a Decision element, and an entry condition. If you cannot state the rule in one sentence, simplify it before you build it.

Record Locking, Recall and Reassignment

Choose a locking approach before configuring approval steps. For sequential reviews, an approval step can lock the record and optionally allow the approver to edit it. For concurrent approval steps, do not let each step lock the same record independently. A record can have only one lock, so repeated locking attempts can fail. Instead, use background steps to manage locking at the stage or process level.

Recall and reassignment need explicit design:

• Recall: Practitioners report that recall arrived in Summer ’25 and is available from the approval submission list. Confirm the behavior in your release, and test what happens to pending work items.
• Reassign: Incomplete work items can be reassigned from list views, according to practitioners. Decide who has permission to do it.
• Concurrent approval steps: Lock the record once before the reviews begin and configure the review steps to start after locking completes. Unlock it at the appropriate stage or process exit, including rejection and recall paths. Test failures to confirm the record is not left locked unexpectedly.
• Resubmission: Define what happens after a rejection. Decide whether the submitter can edit and resubmit, and whether earlier approvers must review again.

Document these rules in the orchestration description, and share them with submitters and approvers. Approvers and submitters will ask what happens after a recall, and a written answer saves repeated questions.

Migrating an Existing Classic Approval Safely

A rebuild is a migration, and migrations need a sequence. Follow the same order for every approval you move, so the process becomes routine and each cutover carries less risk.

• Inventory the current process: Record its criteria, approvers, actions, pending requests, reports, and dependent automation.
• Build the replacement in a sandbox: Configure the Flow Approval Process and its associated flows, documenting intentional differences from the classic design.
• Compare isolated test runs: Use separate records or reset equivalent starting data between tests. Compare decisions, status values, locks, notifications, and related-record changes.
• Plan pending requests: Decide how existing classic requests will finish and how users will distinguish them from new submissions.
• Control the cutover: Deploy and validate the dependencies, then switch submission routes so new requests cannot enter both designs.
• Define the rollback: Document how to stop new submissions, handle requests already started in the replacement, restore the earlier submission route, and reconcile any completed actions.

Tell users what changes. If the Submit for Approval button disappears or the Approval History list looks different, a short note prevents a wave of questions. Update reports and dashboards in the same release, because leaders notice missing numbers faster than any defect.

Notifications, Reminders and Escalation

An approver who never sees the request cannot approve it. Salesforce’s Trailhead module says assigned users receive an email with a link to the record, and that they can find all assigned work on the Orchestration Work Items list page. Practitioners report that the standard notifications work well, so start with those before you build custom ones.

Plan three things beyond the first email. First, decide when to remind approvers, such as after one business day without a decision. Second, decide who steps in when a request stalls, whether a manager, a backup approver, or a queue. Third, decide how submitters learn the outcome, through a notification, a status field, or both.

Reminders and escalation are design choices, not automatic features, so confirm what your release supports before you promise them. A common approach is a background flow that checks for old pending requests and notifies a backup. Test it with inactive and absent approvers, because stalled approvals usually trace back to people who are away, not to broken flows.

Reporting on Approvals With the Approval Objects

Salesforce’s Flow Approval Process data model shows the records used to track submissions, approval work items, and orchestration activity. Use it to understand how Approval Submission, Approval Submission Detail, and Approval Work Item relate to the supporting orchestration records. Compare the reporting available from these records with your existing classic approval reports before deciding whether a rebuild is necessary.

The object reference adds detail. The ApprovalSubmission object represents the instance of an approval request submitted for a record, and it is available in API version 62.0 and later. The ApprovalWorkItem object contains run-time information about each step and tracks assignees and their decisions. It has a master-detail relationship with ApprovalSubmission and is available in API version 61.0 and later.Use these objects to build reports on cycle time, pending items by approver, and rejection rates. Existing reports built on classic approval objects will not show Flow approvals, so plan to rebuild them.

Testing and Debugging an Approval Orchestration

Test an approval like a process, not like a single flow. A request moves through several flows, several people, and several statuses, so a defect can hide anywhere along the path. Each stage, step, and decision is a path, and each path needs a test record. Build a list of scenarios before you start, and mark each one as passed, failed, or untested.

Cover these scenarios in a sandbox:

• Happy path: Submit, approve at every stage, and confirm the final status and background actions.
• Rejection: Reject at each stage and confirm the record, notifications, and tasks.
• Recall: Recall a pending request and check what happens to work items.
• Absent approver: Assign a user who is inactive or has no access, and see where the request stalls.
• Record edits: Change the record while an approval is pending, with and without locking.
• Volume: Submit a batch of records and watch for limit errors.

Practitioners report that debug mode for orchestrations arrived in Winter ’26, so check whether your release offers it. Supervisors can also monitor running orchestrations in the Orchestration Runs list view and cancel or debug them, according to Salesforce’s Trailhead module. Test with approver profiles, not only an admin account, because permissions often cause the failures users see first.

Handling Failures With Fault Paths

Handle failures at two levels: within the flows that perform individual actions and within the stages of the Flow Approval Process. Configure notifications so the responsible team receives useful details, including the affected record, submission, stage, and failed action. If you create a log record, test whether it remains available after the failure.

Stage fault paths need particular care. Salesforce can mark an approval submission Approved when a fault path finishes successfully even though no approval work items were completed. Do not end a fault path after only logging an error or sending a notification. Check which approval work items were completed and route the request to the review or final action that the business policy requires.Test errors before the first approval, between approval stages, and during final actions. Confirm the submission status, completed work items, record changes, notifications, and lock state. An approval failure does not necessarily reverse changes made earlier in the process, so document any recovery work an administrator must perform.

Permissions, Visibility and Rollout

Many approval problems are permission problems. An approver who cannot see the record, the Work Guide, or the trace component will report that nothing works. Check access for every role before rollout.

Review these items:

• Object and field access: Approvers need access to the record and to any field the screen flow reads or updates.
• Page components: Add the Work Guide and the trace component to the record page for the right apps and profiles.
• Flow access: Approvers and submitters need permission to run the screen flows and any flow the orchestration launches.
• Designer access: Practitioners report a permission for limited users to manage approval flows, with changes routed for activation. Confirm what your release offers.
• Groups and queues: Audit membership so every step has someone who can act.

Keep an eye on mobile and email use as well, since many approvers act from a phone. Confirm the work item and the record page display well on the devices your approvers use. Roll out in stages. Start with one team, gather feedback for a week or two, and fix the rough edges before expanding. Keep communication short and specific, and send it before launch, not after the first complaint: where the work item appears, how to approve, and who to contact for help. If you want a review of your approvals before launch, our free Salesforce audit scores automation as one of its areas and returns a fix plan.

Flow Approval Process Constraints to Plan For

Flow Approval Processes differ from classic approvals in submission, work-item handling, reporting, and configuration. Review these differences before deciding whether to rebuild:

• Submission interface: Record-triggered approval processes start automatically. For manual submission, use a supported Request Approvals component, custom button, or another supported automation.
• Approver selection: Supported Request Approvals configurations can collect a submitter-selected approver through the firstApprover resource. Configure the relevant steps to use that resource.
• Decision outputs: Approval screen flows must return Approve or Reject through the required approvalDecision output. Model requests for changes and other business states separately.
• Group decisions: Choose first-response or unanimous behavior deliberately, and account for the restrictions that apply to unanimous work items.
• Version limits: Salesforce documents a maximum of 50 versions per Flow Approval Process. Plan version maintenance and dependency reviews.
• Availability: Flow Approval Processes is available in supported Lightning Experience editions and does not consume automation credits or orchestration runs. Optional integrations can have separate requirements.

When an approval needs specialized logic, you can hire a Salesforce developer for those components. For broader projects, our Salesforce implementation services cover setup, integration, and post-launch support.

Common Mistakes to Avoid

Most failed approval projects share the same few mistakes. Check your design against this list before you build.

• Leaving dependencies unfinished: Identify supporting flows during planning, then complete, test, and activate the required dependencies before activating the Flow Approval Process.
• Ignoring outcomes: Practitioners report that the standard pattern passes back only approve or reject. Decide how other outcomes work before launch.
• Testing only as an admin: Approvers fail on permissions that an administrator never sees.
• Forgetting absent approvers: A named user who is on leave stalls the request.
• Locking too much: A locked record blocks fixes, so give submitters a clear recall path.
• Leaving old reports behind: Reports built on classic approval objects will not show Flow approvals.
• Skipping documentation: Without notes on stages and approvers, the next administrator guesses.

Fix these in the design stage, when changes cost minutes. After launch, the same fixes cost approvals that stall in front of customers.

Governing Approvals After Launch

An approval that nobody owns drifts. Approvers leave, groups change, and criteria no longer match the business. Set a few standards so the process stays reliable.

Agree on these habits:

• Naming: Include the object, trigger, and purpose in every orchestration and flow name.
• Ownership: Assign one owner for each approval, with a named backup.
• Documentation: Record the stages, approvers, outcomes, and exceptions in the description.
• Reviews: Check failed runs, stalled requests, and approver lists every quarter.
• Change control: Build in a sandbox and deploy related flows together.

Our guide on preventing technical debt and security issues covers the wider practice. If your team lacks time, a managed arrangement can own the upkeep, and our comparison of hourly consultants and managed services explains how to choose.

Conclusion

Flow approval orchestration gives Salesforce teams more control than classic approvals, with stages, parallel steps, background actions, and approval data they can report on. It also asks for more planning. Map the approvers and outcomes first, build the flows, assemble the orchestration, and test every path before anyone relies on it.

Start with an approval whose routing, visibility, or maintenance problems justify a rebuild. Define the improvement you expect, build the replacement in a sandbox, and compare isolated test runs against the existing process. Plan pending requests and cutover before enabling new submissions. Measure the result before moving to the next approval, and document the decisions future administrators will need.

A Team of 100+ Salesforce Professionals Backed by Certified Experts

VALiNTRY360 brings together 100+ Salesforce professionals, backed by certified experts in administration, development, data, AI, consulting, and marketing automation. Our listed certifications include Platform Administrator II and Platform App Builder, which cover the admin and design skills approval design relies on.

We can review your current approvals, build replacement orchestrations, test every path, and support the cutover. Meet the team on our about us page, and connect with us to discuss your requirements.

FAQs

What is a Flow approval process in Salesforce?

A Flow Approval Process manages record approvals through stages, approval steps, background steps, and decisions. Approval steps create work items for reviewers, while background steps perform supporting actions. It uses Flow Orchestration technology but has dedicated approval process types, configuration requirements, and approval records.

Do classic approval processes stop working?

Introducing Flow Approval Processes does not require replacing every classic approval. Existing classic processes can continue while you evaluate which approvals would benefit from rebuilding. Review routing, reporting, user experience, and maintenance requirements before deciding to migrate a process that already works reliably.

What are stages and steps in an approval orchestration?

A stage groups related steps into a phase, such as manager review or finance review. Steps can run sequentially, concurrently, or when configured requirements are met. Approval steps create review work items, while background steps run autolaunched flows for supporting actions.

What is the difference between interactive and background steps?

General Flow Orchestration uses interactive steps for user tasks. In dedicated Flow Approval Processes, human reviews use Approval Steps that reference active screen flows. Background Steps run autolaunched flows. Approvers can complete reviews without running the screen flow, so required follow-up actions belong in background steps.

Should I use a record-triggered or autolaunched orchestration?

Choose Record-Triggered Flow Approval Process when a qualifying record creation or update should start approval automatically. Choose Autolaunched Flow Approval Process when a user or another automation should initiate submission. Select the dedicated approval process type rather than a generic orchestration when following this guide.

What should I build before the orchestration?

Identify the approval screens, background actions, inputs, and outputs during planning. Complete, test, and activate the associated flows before activating the approval process. Approval screen flows require a Text output named approvalDecision that returns Approve or Reject. A Text output named approvalComments is optional.

How do I assign approvers in a Flow approval?

Configure an Approval Step for a user, public group, queue, or resource that determines the assignee at run time. For groups, choose whether one response or unanimous approval is required. Test record access, delegates, unavailable reviewers, and reassignment restrictions before activation.

Can submitters choose their own approver?

Supported Request Approvals configurations let submitters select an approver. Assign the relevant approval steps to the firstApprover resource and configure the component to require that selection. This supports a designated reviewer for those steps; it does not automatically let submitters choose every subsequent approver.

Where do approvers complete their work?

Approvers can complete assigned approval work items through the Orchestration Work Guide on the record page or through the Approval Work Items list view. Email responses are also supported when enabled. Keep required updates and notifications in background steps because the approval screen might not run.

Can I report on Flow approvals?

Yes. Flow Approval Processes stores information in records such as Approval Submission, Approval Submission Detail, and Approval Work Item. Use appropriate report types to examine pending reviews, outcomes, and elapsed time. Classic approvals also support history reporting, but their reports do not automatically include Flow approval records.

What happens to the Approval History related list?

The classic Approval History related list does not provide the history for dedicated Flow Approval Processes. Use the supported Approval Trace component and approval submission and work-item records for visibility. Configure the relevant record-page components and test access with submitters and approvers.

Can an approval be recalled or reassigned?

Submitters can recall their in-progress submissions, and users with the Approval Admin permission can recall other submissions. Eligible open approval work items can be reassigned, but work items from unanimous approval steps have restrictions. Test recall actions, record unlocking, and the handling of outstanding work items.

How do I test a Flow approval before launch?

Test approval, rejection, recall, reassignment, unavailable reviewers, concurrent reviews, record locking, and failures before any reviewer acts. Use representative permissions and realistic record batches. Compare isolated runs against the existing design, and verify final submission statuses so fault handling cannot silently bypass required approval.

Does Flow approval orchestration cost extra?

Salesforce states that Flow Approval Processes does not consume automation credits or orchestration runs. It is available in supported Lightning Experience editions, including Enterprise, Performance, Unlimited, Einstein 1, and Developer. Check separate licensing requirements for optional products or integrations used by the design.

When should I keep a classic approval instead?

Keep a classic approval when it meets business requirements and remains reliable and maintainable. Consider rebuilding when routing, user experience, visibility, or maintenance needs justify the effort. Check existing classic approval reporting before treating reporting alone as a reason to migrate.