Approvals people route around are usually approvals that ask the wrong person, at the wrong threshold, with no way to act quickly. A good Salesforce approval design starts with which decisions truly need sign-off. Then it maps thresholds to approvers, plans for absence, locks the record while it waits, and lets people respond from email, mobile or Slack. Build it in Flow Approval Processes for new work, keep the matrix short, and measure cycle time from day one.
Which decisions deserve a formal approval?
Only decisions where a second person adds judgment or carries accountability. If the answer is always yes under known conditions, write a rule instead of an approval.
Most orgs we review have too many approvals, not too few. Each extra step teaches people that the queue is a formality. Sort every proposed approval into one of three buckets before anyone builds anything.
- Formal approval: the decision changes margin, risk or a commitment, and the approver might reasonably say no.
- Validation rule or automation: the condition is objective, such as a missing field or a discount above a hard ceiling nobody may exceed.
- Delegated authority: a manager trusts a team to decide within a band, so you record the decision without waiting for anyone.
Ask each proposed approver how often they rejected or changed a request last quarter. If the answer is almost never, raise the threshold or remove the step.
Should you build in classic Approval Processes or Flow?
For new approvals, start with Flow Approval Processes, which Salesforce has been extending release by release. Keep working classic processes running until you have a reason to rebuild them.
Salesforce now labels the older tool "classic" Approval Processes. It still works: entry criteria, ordered steps, approvers per step, and actions on submission, approval, rejection and recall. Salesforce has not published a retirement date for it that we can find. New approval features have been arriving in Flow instead.
Flow Approval Processes, built on what Salesforce calls Approval Orchestration, arrived in Spring '25. They run as record-triggered or autolaunched orchestrations made of stages and steps. Approval steps ask a person to decide, and background steps run automation without anyone clicking. Later releases added a recall path, fault paths, work-item reassignment and better debugging. Ask your account team how approval orchestrations are licensed in your edition before you plan volume. Confirm current packaging for your edition with your Salesforce account team.
Flow approvals have trade-offs. Approvers must be resolved inside the approval step, so a submitter cannot pick the next approver by hand. Our guide to Flow and Apex covers where code still earns its place.
How should the approval matrix be designed?
Write the matrix as a table before configuring anything: the trigger condition, the approver, and what happens on each outcome. If finance and sales cannot agree on the table, software will not settle it.
Thresholds should be few and round. Three discount bands are easier to explain and test than seven. Base each band on something the record already holds, such as discount percent, total contract value or term length.
Decide how steps relate to each other. Sequential steps suit escalating authority, where the CFO only sees what the sales director already approved. Parallel steps suit independent reviews, such as legal and finance looking at the same contract at once. When several people share one step, choose between unanimous approval and first response. Unanimous suits risk reviews. First response suits a pool of interchangeable approvers.
| Approval type | Typical trigger | Who approves | Design pitfall |
|---|---|---|---|
| Discount | Discount above a set band on a quote or opportunity | Sales manager, then finance above a higher band | Too many bands, so every deal waits on someone |
| Non-standard contract terms | Changed payment, liability or renewal terms | Legal and finance in parallel | Running reviews in sequence when they are independent |
| Expense or spend | Amount above a manager's own limit | Cost-center owner from a lookup field | Routing by manager hierarchy when budgets follow cost centers |
| Credit or payment exception | Terms outside the customer's credit standing | Credit or AR lead | Approving in Salesforce while the ERP still holds the order |
| Pricing or product exception | Product sold outside its normal bundle or region | Product or pricing owner | No owner named, so requests sit unassigned |
| Case or refund exception | Credit or refund above an agent's authority | Service supervisor queue | Single named approver with no backup |
How do you assign approvers so requests reach the right person?
Route from data the record already holds, not from names typed into the process. Hard-coded users break the first time someone changes roles.
- Manager hierarchy: classic processes can follow the standard Manager field or a custom hierarchy field on the User record. This works only if HR keeps managers current in Salesforce.
- Related user fields: a lookup such as Deal Desk Owner or Cost Center Owner on the record routes to whoever owns that responsibility today.
- Queues: a group can share requests, which suits finance or legal pools. In classic processes, approving by email reply does not work for queue assignments, so plan queue work in the app.
- Formula or Flow logic: Flow approvals can calculate the approver, which helps when routing depends on region, product line and amount together.
What happens when an approver is away?
Plan for absence on day one, or approvals will stall during the first holiday. Salesforce gives you delegation and reassignment, but both need someone to own them.
Each user record has a Delegated Approver field. In classic processes, a step can allow that delegate to act on the approver's behalf. Flow approvals notify delegates and support reassigning work items to another user. The weak point is process, not software. Ask approvers to set a delegate before leave, and give an operations owner rights to reassign stuck items.
What should be editable while a record waits for approval?
Lock the fields the approver is judging, and nothing else if you can avoid it. A locked record that blocks unrelated work pushes people back to email.
Classic processes lock the record on submission by default. You choose whether only administrators, or administrators and the current approver, can edit it while locked. Flow approvals offer record locking as an option. Decide also what happens after approval. If someone raises the discount on an approved quote, a validation rule or flow should reset the status and require resubmission. Without that, approval means very little.
How should recall and rejection work?
Submitters need a clean way to pull a request back, and rejections need a reason and a next step. Both paths deserve as much design as approval does.
- Recall: allow the submitter to recall, unlock the record, and notify approvers so nobody acts on a stale request.
- Rejection: require a comment, return the record to an editable status, and tell the submitter what would change the answer.
- Partial rejection: in multi-step designs, decide whether rejection at step two sends the record back to the start or ends the request.
- Resubmission: keep earlier attempts visible so approvers see what changed.
Can people approve from email, mobile and Slack?
Yes, with conditions that vary by approval tool. Test each channel with real approvers before launch.
Classic processes support approving by replying to the notification email once Email Approval Response is enabled. The Salesforce mobile app lists pending approvals, though it cannot unlock a locked record. Flow approvals send email notifications that link to the record, and the Approvals app gives approvers a list of their pending work.
Slack support is changing quickly. Salesforce documents approval notifications in Slack for classic processes. Release coverage of Summer '26 describes approving and rejecting Flow approvals inside Slack through the Salesforce for Slack app. Treat Slack approvals as a feature to confirm in your org and edition, not an assumption. Our Slack guide covers the wider integration.
How do you keep approvals moving without promising fixed response times?
Set reminders and escalation rules that match what the business will actually enforce. A reminder nobody acts on is noise.
Classic processes have no built-in timer that escalates a pending request. Teams typically add a scheduled flow that finds requests pending past a chosen age and reminds the approver or alerts a manager. Flow approvals can use background steps and orchestration logic for similar purposes. Agree reminder rules with approvers and publish them as targets, not guarantees.
How do you measure approval cycle time and find bottlenecks?
Record submission and decision times, then report on elapsed time by approval type, step and approver. Bottlenecks are usually one step or one person.
Approval history lives in its own system objects, and reporting on it is not always simple. Many teams write submission date, approval date and final status back to the record, then report there. Flow approvals store each request as an approval submission with related work items, which the Approvals app can list. Watch three numbers: median time to decision, share of requests rejected, and share approved unchanged. A step that approves nearly everything unchanged is a candidate for delegated authority.
Does the approval history satisfy auditors?
It gives you who approved what, when and with which comment, which covers most internal audit questions. Gaps tend to appear around edits made after approval.
Classic processes show an Approval History related list on the record. Flow approvals offer an Approval Trace component for the same purpose. Pair either with field history tracking on the fields being approved, so you can prove values did not change after sign-off. Restrict who can delete records or edit approval fields.
How should you test an approval matrix before launch?
Test every row of the matrix, every boundary value and every exit path, using real users' profiles. Most failures appear at the exact threshold or when a manager field is blank.
- Build a test sheet with one row per band, including values just below, at and just above each threshold.
- Run each case as a submitter with a realistic profile, not as an administrator.
- Test rejection, recall, resubmission and edits after approval, not only the happy path.
- Blank out a manager or owner field and confirm the request fails clearly rather than disappearing.
- Confirm each notification channel reaches the right person, including delegates.
What should the first approval release include?
One approval type that hurts today, built cleanly, measured from launch. Prove the pattern before adding the rest.
- Pick the approval with the most email traffic, often discounts or contract terms.
- Agree the matrix in writing with its approvers and remove any step that never says no.
- Build it in Flow Approval Processes unless a working classic process already covers it.
- Set delegation, locking, recall and rejection rules, plus a reminder for stale requests.
- Add submission and decision dates to the record and a simple cycle-time report.
- Review the numbers with approvers after a full sales or billing cycle, then adjust thresholds.
If your approvals already exist but people work around them, an optimization review is usually faster than a rebuild. Abstrakt Solutions can help with either path, as a Salesforce Select partner since 2017.
