12.4 Flow Approval Processes, Monitoring & Troubleshooting
Key Takeaways
Flow approval processes (approval orchestration), introduced in Spring '25 and expanded in Summer '25 and Winter '26, are built directly in Flow Builder and consume no orchestration credits.
Autolaunched approval orchestration has no trigger and launches from other processes or a custom button; record-triggered approval orchestration fires when the record being approved is created or updated.
Approval Steps call a screen flow, while their step configuration assigns a User, Queue, Group, or runtime Resource — a User resource must contain the username, not the User Id; Background Steps run autolaunched flows with inputs set from the step.
Recall paths sit on the start node, split by stages, and allow only background steps; the Evaluate Approval Requests template's approvalDecision output accepts only Approve and Reject.
Monitor flows via error emails, paused and failed interviews in the Flows list in Setup, the debug tool's Run as Another User and rollback mode, and declarative tests written before activation.
Flow Approval Processes, Monitoring & Troubleshooting
Classic approval processes (Chapters 7.1-7.2) are now joined by Flow approval processes — formally, approval orchestration. Introduced in Spring '25 and expanded in Summer '25 (recall paths, stage fault paths, a creation wizard) and Winter '26 (a Debug Panel; a limited Approval Designer permission with Submit for Activation, which routes an activation approval request that can itself be recalled), approval orchestration is built directly in Flow Builder and consumes no orchestration credits — the feature does not consume orchestration runs, but required editions, user permissions, and any underlying services still apply.
Two Flow Types, One Structure
| Flow Type | How It Starts | Typical Launch |
|---|---|---|
| Autolaunched approval orchestration | No trigger | Launched from other processes or a custom button |
| Record-triggered approval orchestration | Fires when the record being approved is created or updated | The record save itself |
Structurally, stages contain steps, and decision elements route between stages. Before building the orchestration, map out and activate every sub-flow first — the orchestration references them, and building in the opposite order forces rework.
The Two Step Types
Approval Step (Interactive)
An Approval Step requires a screen flow to be selected. In the Approval Step configuration, assign a User, Group, Queue, or runtime Resource; configure notification, record ID, locking, and approver editability there. The associated screen flow collects the review outcome through its approvalDecision Text output. Approvers can also decide through supported email or work-item surfaces without running that screen, so put subsequent business changes in a Background Step.
Warning
A User resource must contain the username, not the User Id. A Resource assignee resolves from a username, group API name, or queue API name. A Salesforce record ID is not the expected resource value; select the correct configured input before the step starts.
Background Step (Automatic)
A Background Step uses an autolaunched flow with no user interaction; its input variables are set from the step. Stage completion can be governed by custom conditions or by an Evaluation Flow that returns the IsOrchestrationConditionMet output variable.
Work-Item and Failure Checklist
Verify the approval-step Record ID, runtime assignee resource, active review flow, required approvalDecision output, and access to the reviewed record. A User resource must resolve before the review screen starts; querying an approver inside that screen cannot fix routing of the work item that was needed to open it. Use a preceding background flow or existing orchestration input when approver selection requires record data.
To troubleshoot, capture the flow version, interview/run identifier, failing element, timestamp, running context, and exact error. In Setup review Paused and Failed Flow Interviews and the Automation/Flows views available in the org; Flow Approval submissions and work items have their own operational views. Reproduce with the same inputs in a sandbox, then test the complete save path and relevant bulk scenario. A standalone debugger run does not prove that every interacting trigger and flow succeeds. Keep reusable assertions for successful routing, rejection, recall, and missing assignees.
Official Source Check
Checked October 19, 2026: Approval step configuration and resource assignment.
Recall Paths, Fault Paths, and the Ready-Made Template
The recall path is configured on the start node, splits by stages, and permits only background steps — a recall never pauses for a human decision. Each stage defines its own fault path behavior; note that a step's flow failure can produce both flow and orchestration error notifications; inspect the configured recipients and both diagnostics.
For approver decisions, the ready-made Evaluate Approval Requests screen-flow template captures the approve/reject interaction. Its approvalDecision output variable only accepts the values Approve and Reject — adding custom option values to the template breaks the step.
User-Facing Surfaces
| Surface | What It Provides |
|---|---|
| Orchestration Work Guide component | Guided work items for the approver; auto-hides when empty |
| Approval Trace component | Work item status, comments, and assignments |
| Approvals Lightning app | List views for Approval Submissions, Submission Details, and Work Items, with reassign and review actions |
Note
The classic Approval History related list stays empty for orchestration approvals — the Approval Trace component and the Approvals app are the audit surfaces. Candidates who reach for Approval History on a Flow approval question are answering for the wrong feature.
Limits and Traps
- Maximum 50 versions per orchestration.
- Manually selecting the next approver mid-process is not supported — the step assignment is designed in advance but can resolve dynamically from a runtime Resource. If a requirement demands ad-hoc approver changes mid-flight, classic approvals still hold that advantage.
- Review migration considerations and test in a sandbox before moving off classic approvals — the surfaces, emails, and audit trails all differ.
- In Winter '26, the Debug Panel supports rollback mode, and async steps need the Manually Set Output Variables option.
Monitoring and Troubleshooting Flows
The blueprint objective maintain, monitor, and troubleshoot flows spans every flow type, orchestrations included:
- Flow error emails are sent on failed flow runs. Keep the standard submitter notifications on so requesters are informed through the supported channel rather than left chasing silence.
- Paused and failed flow interviews are reviewed from the Flows list in Setup — open the flow, inspect the interview list, and see exactly which element failed with which message.
- The Flow Builder debug tool supports Run as Another User (to reproduce sharing-dependent behavior) and rollback mode (to test without committing data).
- Write declarative flow tests before activation — assertions running against your test data catch regressions the day they are introduced, not the week after.
- Practice version discipline: create a new version, test it, then activate. Never deactivate a live version to edit it in place.
Classic versus Flow Approval Processes
| Consideration | Classic Approval Process | Flow Approval Process |
|---|---|---|
| Where it is built | Setup approval configuration | Flow Builder orchestration |
| Approver flexibility | Next approver can be selected manually mid-process | Configured per step; runtime Resource can resolve user/group/queue dynamically |
| Recall behavior | Standard recall on the approval process | Recall path on the start node; splits by stages; background steps only |
| Audit surface | Approval History related list | Approval Trace component and the Approvals app |
| Cost | No extra cost | No orchestration credits consumed |
| Choose it when | Simple linear approvals on established setups | Multi-stage approvals needing flows, decisions, and modern components |
Best Practices & Common Exam Traps
- Username, not User Id, in the approver's User resource.
- A step failure can generate flow and orchestration diagnostics; check configured error-notification recipients.
approvalDecisionaccepts only Approve and Reject — custom values break the Evaluate Approval Requests step.- Approval History stays empty for orchestration approvals; trace activity with Approval Trace.
- Recall means background only: the recall path splits by stage and never runs screens.
- Sub-flows first: map and activate them before building the orchestration.
A newly activated approval orchestration fails every time a submission reaches the Approval Step. The orchestration provides an approver Resource containing an 18-character User ID instead of a username. What is the most likely cause and fix?
The orchestration has exceeded its 50-version storage limit, so the oldest versions must be permanently deleted from Setup before the current version can be reactivated
The Approval Step is missing a Background Step to resolve the approver, so an Evaluation Flow must be added first
The User resource for an approver must contain the username, not the User Id, so the approver Resource should resolve to the username
The record was not locked, so record locking must be enabled on the Approval Step for the approver resource to resolve
Universal Containers is building a discount approval orchestration. When a submitter recalls a request, the team must automatically launch a reversal that updates the quote with no human interaction. How should the app builder configure this?
Add a recall path on the start node, split it by stages, and include only background steps that run the reversal autolaunched flow
Add a recall path to every individual Approval Step in the orchestration, split it by stages, and include a screen flow so the submitter can confirm the reversal before it runs
Keep the classic approval process recall behavior, because Flow approval processes do not support recall at all
Configure a stage fault path that calls the reversal flow whenever any approver rejects the request
An operations lead reports that a record-triggered flow failed overnight while updating related inventory records. She wants to locate the failed run, understand the error, and reproduce it safely without writing data. What should the app builder do first?
Deactivate the flow immediately, export the setup audit trail, and rebuild the automation as a brand-new version before any diagnosis
Wait for the next scheduled run to occur and monitor the interview live from the fault path configuration screen
Query the Approval History related list in the Approvals app, because failed interviews are logged there for record-triggered flows
Open the flow from the Flows list in Setup, inspect the failed interview, then rerun it with Run as Another User and rollback mode
Sections you finish are checked off in the contents.
You've completed this section
Continue exploring other exams