--- title: "Approval process or flow" url: "https://trailassembly.com/approval-process-vs-flow/" topic: "Flow and Automation" published: "2026-09-12T04:42:27+00:00" updated: "2026-10-06T13:53:20+00:00" --- # Approval process or flow **Approval processes give you three things flow does not: automatic record locking, delegated approvers, and a queryable approval history.** If you need any of those, use an approval process and drive it from flow with the Submit for Approval action. Rebuild in flow when the routing logic is genuinely complex, or when the approval has to happen inside a screen experience users are already in. ## What you lose by rebuilding in flow **Record locking.** When a record enters an approval process, Salesforce locks it. The submitter cannot edit the thing they submitted while it is being reviewed. Flow has no equivalent element. Locking from flow means an invocable Apex method calling `Approval.lock()`, or a [validation rule](https://trailassembly.com/validation-rule-vs-flow/) reading a status field, which is a rule everyone with [Modify All Data](https://trailassembly.com/view-all-modify-all-explained/) can ignore. **Delegated approvers.** Each user record has a Delegated Approver field. Approval requests route to that person as well, without you building anything. In flow you would have to look up the delegate, decide when it applies, and handle the case where both respond. **Approval history.** The Approval History related list, plus the ProcessInstance, ProcessInstanceStep and ProcessInstanceWorkitem objects, come for free and are queryable in SOQL and reportable. Rebuild in flow and you are building a custom object to hold that, then a related list, then reports. That is real work, and it is work auditors will ask about. **The bits you forget to cost.** Approve or reject from an email reply. Recall. Approvals in the Salesforce mobile app. Reassigning a pending request. Each one is a checkbox in the approval setup and a feature request in a flow build. ## What flow does better Routing that depends on data, not on a static step list. An approval process evaluates step criteria in order and assigns to a user, a queue, or a hierarchy field. If your rule is “route to whoever owns the largest contract on this account, unless the amount is under 5,000, in which case skip approval entirely”, expressing that in step criteria is painful and expressing it in flow is a Get Records and a Decision. Flow also wins where the approval is part of an experience. A screen flow can present the record, collect a justification, show the approver exactly the four fields they care about, and route on their answer. Approval processes hand the approver a standard page and a comments box. And flow handles the surrounding work: reminders on a [scheduled path](https://trailassembly.com/flow-scheduled-paths/) when nobody responds in three days, a Chatter post, a callout to the system on the other side of the approval. Approval processes can trigger a flow, so you often want both rather than one. ## The combination most orgs should build Use the approval process as the engine and flow as everything around it. - A record-triggered flow decides whether the record needs approval at all, and calls the **Submit for Approval** core action when it does. - The approval process handles locking, routing, delegation, and history. - Final approval and final rejection actions on the process call flows to do the downstream work. - A scheduled flow chases pending requests older than your service target, reading ProcessInstanceWorkitem. ## When to rebuild in flow anyway Three cases justify it. Approval that is not really approval, such as an internal review with no locking requirement and no compliance story. Approval that has to happen in a place approval processes cannot reach, like an Experience Cloud site page or a guided screen flow. And routing so conditional that the approval process would need a dozen entry criteria and a separate process per scenario. Outside those, rebuilding is a lot of effort to reproduce features you already own. Flow Orchestration sits between the two and is worth evaluating for multi-stage, multi-person work, though check what it costs in your edition before you design around it. ## Frequently asked **Can a flow approve a record on a user’s behalf?** Yes, via an invocable Apex method wrapping `Approval.process()`. There is no standard flow action for responding to a request, only for submitting one. **Does the record lock stop my automation too?** It stops user edits and, depending on the process’s Record Editability setting, some automated updates. Flows and Apex running in [system context](https://trailassembly.com/flow-system-vs-user-context/) can still update locked records, which is often how a “locked” record quietly changes anyway. **Are approval processes being retired?** No. Process Builder and [Workflow Rules](https://trailassembly.com/migrate-workflow-rules/) are the ones on that path. Approval processes are not. **How do I report on how long approvals take?** Query ProcessInstanceStep, which carries the actor and the timestamp for each step. It is the single best argument for keeping the standard engine. --- Source: https://trailassembly.com/approval-process-vs-flow/ Trail Assembly — independent Salesforce write-ups.