On a recent project for a regional telecom client, a sales rep submitted an Opportunity with a 42% discount late on a Friday afternoon. The assigned approver — the sales manager — saw the notification, decided to review it properly on Monday, and went offline for the weekend. The rep, meanwhile, realized she had entered the wrong product bundle and needed to correct the line items before the approval went through. She couldn't. The record was locked. No one short of an admin with Modify All Data could touch it, and the admin on call didn't realize the urgency until the deal's close date had already passed.
That single incident captures almost everything we want to talk about when we discuss Approval Process design: not the happy path, but the edge cases that expose under-specified decisions. We've seen the same failure modes across multiple implementations — a locked record with no available approver, a recall that surprises everyone by not rejecting anything, a multi-step process that collapses because the Manager field was never populated for half the user base. The core concept is simple; the implementation details are where orgs consistently get into trouble.
The six components you need to get right
An Approval Process is built from six pieces, and the most common mistakes come from confusing what each one is responsible for.
Entry criteria define when the Submit for Approval button becomes available. If a record doesn't meet the criteria, the button either doesn't appear or does nothing — the user cannot force a submission. We always review entry criteria carefully because overly broad criteria (or no criteria at all) mean reps can accidentally submit records that aren't ready, triggering the lock before the data is clean.
Approver assignment lives in the approval step, not the entry criteria. We see this confused regularly: admins try to encode routing logic into criteria filters when it belongs in the step configuration itself. Entry criteria answer "should this record go through approval at all?" — approver assignment answers "who decides?"
Initial submission actions fire the moment the record is submitted. The standard pattern is: lock the record, send the notification email, and stamp a field (Stage = "Pending Approval"). These actions are reversible through Recall, which matters more than most people realize — more on that below.
Approval steps are the sequential decisions. Each step has its own approver logic, its own behavior on rejection, and its own criteria for whether the step is even required. A single Approval Process can carry multiple steps, and we almost always prefer that over multiple separate processes on the same object.
Final approval and rejection actions fire once the last step resolves. Approval unlocks the record and stamps it approved; rejection unlocks it and stamps it rejected. Both send notifications. These are straightforward — the design complexity is upstream, in the steps.
Recall is where we spend a disproportionate amount of time during requirements gathering, because clients consistently assume it works like a rejection. It does not.
Record locking: the feature that bites teams who haven't planned for it
When a record enters an approval process, Salesforce locks it automatically. The record owner cannot edit it. The submitter cannot edit it. The only people who can touch a locked record are the assigned approver (through the approval interface), admins with Modify All Data, and users explicitly granted the Modify Locked Records system permission.
This is exactly what makes Approval Process the right tool for enforced review gates. A Validation Rule can prevent certain saves, but it can't prevent an admin from making changes, and it can't prevent the record from being edited between the validation check and the next save. An Approval Process with record locking genuinely enforces the hold. Nothing moves until a human approves or rejects.
The consequence of this — what the telecom story illustrates — is that any scenario where the approver might be unavailable needs a fallback plan built into the design, not handled as an afterthought.
Approver routing: matching the option to the org structure
Salesforce offers four main routing options, and we pick based on how the org actually makes decisions rather than what's easiest to configure.
Routing to a specific named user is the simplest option and the one we use least. It doesn't scale, and it creates a single point of failure. The one time it makes sense is when a central compliance officer must review every submission of a particular record type — there's genuinely only one person, and that's intentional.
Manager of the submitter is the most common pattern for hierarchy-aligned approvals, and it works well when the Manager field on every User record is populated and kept current. That "when" is load-bearing. On more than one project we've inherited orgs where 20–30% of user records had no manager set, which meant submitted records were routing to null and disappearing into a no-approver void. We now treat Manager field completeness as a data hygiene prerequisite we verify before go-live, not a configuration detail.
Queue-based routing is what we recommend for any approval that has availability risk. Any queue member can action the approval, which means the process doesn't stall if one person is out. For month-end deal approvals or anything time-sensitive, queue routing with a defined response SLA is more robust than trusting that delegated approvers will be configured correctly.
User field on the record is the most flexible option for project- or deal-specific routing, where the approver varies by engagement. A Lookup field on the Opportunity (say, "Deal Sponsor") points to the relevant user, and the approval routes to whoever is in that field at submission time. The risk is obvious — if that field is blank or wrong, the routing breaks — so we pair this with a Validation Rule that enforces the field is populated before submission.
Multi-step approvals: one process, multiple steps
A discount approval we built for a distribution client had two tiers: the direct sales manager approved discounts between 15% and 30%, and the Sales Director had to sign off on anything above 30%. The naive implementation would be two separate Approval Processes with different entry criteria. We never do it that way.
Two processes on the same object means two audit trails, two sets of notifications, and the real possibility that both processes trigger simultaneously if the criteria overlap. Multi-step within a single process keeps everything in one place — one audit trail, one set of final actions, one recall path. Step 2 only activates if Step 1 was approved, and the criteria per step handle the routing logic cleanly.
The only case where separate processes make sense is when the approval workflows are genuinely independent — different objects, different triggers, different stakeholders — rather than sequential tiers of the same decision.
Delegation: configure it before you need it
Every approver can designate a delegated approver who has identical authority to approve or reject on their behalf. The delegation is set on the approver's User record, and the delegated approver sees the same approval requests in their queue. This is the right solution for planned leave coverage.
The problem is that it has to be configured in advance, and in practice it often isn't. An approver who goes on unplanned leave — or simply doesn't know to set up delegation — leaves pending approvals with no one to action them. The admin has to step in manually, either reassigning the approval task or having a Modify All Data user approve directly.
For high-stakes or time-sensitive approvals, we build queue-based escalation into the process itself rather than relying on delegation being correctly set up. Route to the manager; if no response in 48 hours, the process escalates to a regional director queue. The Approval Process can't do time-based escalation natively, but a scheduled Flow can reassign or escalate approval tasks on a timer. We consider this a standard addition for any approval process where latency has real business consequences.
Recall: what it does, and what it doesn't
Recall is the action that returns a submitted record to Draft status before a decision has been made. It reverses the initial submission actions — if the submission stamped the Stage field and locked the record, the recall unlocks the record and reverses the field update (assuming a reversal action is configured). It does not unsend notification emails that were already delivered.
What recall does not do is reject the record. A recalled record is available for resubmission. This is the intended behavior when a rep submitted too early and needs to correct data before routing for approval. It is not the right behavior when the business requirement is "a recalled record cannot be resubmitted without manager intervention."
We see this assumption about recall most often in regulated industries — financial services, healthcare distribution — where teams assume that pulling back an approval request means the record is flagged or blocked. It isn't. If the requirement is that a recalled record needs a secondary review before resubmission, that enforcement has to come from a Validation Rule or a Flow that checks a status field and blocks the submit path. Approval Process alone won't do it.
How we approach this on every project
Before we configure a single step, we work through the failure modes with the business stakeholder: what happens if the approver is unavailable? What does the submitter expect when they hit Recall? Is there a time-sensitive escalation path? What state should the record be in if the approval stalls for a week?
Most of these questions surface requirements that the original brief didn't capture — and it's far cheaper to answer them in a design session than to discover them after go-live when a locked record is blocking a deal. The Approval Process tooling in Salesforce is genuinely capable of handling complex routing logic; the failure mode we see most often isn't a platform limitation, it's under-specified requirements for the edge cases that happen to every org eventually.
Get the six components right, build for approver unavailability, and be precise about what recall means in your context — that covers the majority of what goes wrong.
