Why Salesforce Approval Processes Break Down at Scale

Most Salesforce approval problems start small. A quote sits for a day because the approving manager is on a flight, or a discount request routes to someone who left the company last quarter. At 50 users, people patch these gaps with a quick chat message. At 500 users spread across regions and product lines, the same gaps show up as slipped deals at quarter end and audit questions that take weeks to answer. The approval logic stayed frozen while the business around it kept moving.

This guide explains why a Salesforce approval process that worked well at launch tends to fail as volume and deal complexity grow. It walks through the platform limits that matter and the design choices that make classic approvals hard to change. It then covers how to find approval bottlenecks in your own org and what the newer flow-based tool changes for admins in 2026. It’s written for the admins and RevOps leads who own this work.

TL;DR

Salesforce approvals fail at scale mostly because classic approval designs are rigid once activated, and because they route work through user fields and hierarchies that drift out of date as the company reorganizes. Volume makes every weak spot visible. Locked records stall simple edits, and a few senior approvers end up holding most of the queue as discount requests pile up at quarter end. Hard platform ceilings exist too, but most teams feel the design and ownership problems long before they reach a numeric limit.

The fix starts with measurement. Pull approval history data to see where requests wait and who holds them. Then cut steps that add delay without adding control, and set thresholds so low-risk requests approve automatically. Every approval that remains should have a named decision owner. For new or heavily reworked approvals, Salesforce now points admins toward Flow Approval Processes, which support conditional paths and parallel steps that classic approvals can’t match. Migrate in phases, starting with the process that causes the most pain.

What a Salesforce approval process does and why teams depend on it

A Salesforce approval process is an automated sequence that decides who must sign off on a record before it moves forward. Each step names the approvers and the criteria a record must meet to enter that step. Around those steps sit 4 groups of actions: initial submission actions, final approval actions, final rejection actions, and recall actions. By default, submitting a record locks it, so only approvers and admins can change it while the request is pending. When the final approver signs off, the process can release the lock and update a status field so the submitter knows the result.

In B2B SaaS companies, the most common uses are commercial. Discount approvals on opportunities and quotes are the textbook example, followed closely by requests for nonstandard contract terms. Finance and HR teams add their own approvals for expenses and new headcount. Over time, these controls stack up on the same objects and draw on the same small group of senior approvers.

Salesforce now has 2 approval tools, and the naming matters. The older tool is called Classic Approval Processes in current Salesforce Help pages. The newer tool, Flow Approval Processes, arrived in the Spring ’25 release and runs on Flow Orchestration inside Flow Builder. Most mature orgs still run the classic version, often with processes built by admins who have since moved on. Nobody fully remembers why each step exists, so nobody feels safe removing it.

Teams depend on approvals because they create a record of who agreed to what and when. The Approval History related list shows each step along with who acted on it and any comments they left. For finance and legal teams, that trail is often the main reason the process exists. When people bypass a slow process with side agreements in email or chat, the audit trail stops matching what actually happened.

The early warning signs of approvals under strain

Approval systems degrade gradually, and the signs appear in behavior before they appear in any report. If several of these sound familiar, your approval design has probably fallen behind your org’s growth:

Reps ask for approval outside Salesforce. They message a VP directly for a verbal yes, then submit the record so the system reflects a decision already made.

Admins clone processes instead of editing them. Each clone adds a new version with slightly different criteria, and the list of processes on key objects keeps growing.

Approvers batch their queue once a week. Requests sit untouched for days, then clear in a single session with little review, which defeats the purpose of the control.

Quarter-end requests spike and stall. Deal desk and finance approvers can’t keep pace, so discount decisions get rushed or deals slip into the next period.

Nobody can say how long approvals take. The data exists in Salesforce, but no one has built a report on it, so debates about delays rely on anecdotes.

These signs point to the same root cause. Every Salesforce approval process encodes assumptions about the company, such as who reports to whom and what counts as a large deal. As headcount and deal mix change, those assumptions go stale while the process keeps running as if nothing happened. Stale approval routing and quiet approval bottlenecks follow from that gap.

Platform limits that surface as orgs grow

Salesforce publishes firm approval process limits, and it helps to know them before a growing team runs into one mid-quarter. The current figures appear on the Salesforce page listingclassic approval limits, and they apply per org. The table below lists the ones that matter most.

Few orgs hit the 1,000-process ceiling. The approval process limits that bite first are the per-object and per-step numbers, since growth concentrates on a handful of objects. Opportunity and Quote often carry the bulk of commercial approvals. If an admin team builds a separate process for each region and product line, the count on those objects climbs quickly, and the 300 active processes per object stops looking generous.

The 25-approver cap per step matters for committee-style approvals. A pricing council or a large deal review board can outgrow a single step, which forces admins to split a single decision across several steps and adds waiting time between them. The 40-action cap per type rarely binds on its own, though it can when teams pack unrelated automation into approval actions.

There’s also a behavioral limit that doesn’t appear in the table. When a record is submitted, Salesforce checks active processes on that object in their set order and runs the first one whose entry criteria match. Only 1 process runs per submission. As the number of processes grows, the order becomes a hidden rulebook. A new process placed above an older one can quietly capture records that used to route elsewhere. Reviewing approval process limits alongside process order gives a far more accurate view of risk than the raw counts alone.

Why classic approval designs resist change

Most scale problems in classic approvals come from rigidity. Once a Salesforce approval process is active, much of its structure is fixed, so every business change forces admins to rebuild. The constraints below explain why many orgs end up with near-duplicate processes.

Activated steps can’t be edited

The first constraint is the one that catches most admins off guard. Salesforce lets you add steps to a classic process only while it’s inactive, as the help article onadding approval steps confirms. The restriction goes further than that. After activation, the list and order of steps is fixed, and so is their reject or skip behavior, even if you deactivate the process later. In practice, changing the approval chain means cloning the process, editing the clone, activating it, and retiring the original.

That workflow is manageable once. At scale, it repeats every time pricing policy or reporting lines change, and old versions linger because records in flight still reference them. After a few years, admins inherit dozens of processes with names like “Discount Approval v4 EMEA,” and the approval process limits on that object start to feel close.

Deployments don’t carry process order

Teams that deploy through sandboxes and pipelines face a second trap. Salesforce’s ownApprovalProcess metadata reference notes that the metadata doesn’t include the order of active approval processes, so admins may need to reorder them in the target org after deployment. Since only the first matching process runs, a correct deployment can still route records to the wrong process if someone forgets that manual step. Release checklists at larger orgs should include a process-order check for every object with more than 1 active approval.

Each process belongs to a single object

Classic approvals attach to a single object. Real approval decisions often span several, such as an opportunity and the credit status of its account. Admins bridge that gap with formula fields and extra automation that copies data onto the object under approval. Each workaround adds a dependency that can break silently when someone changes a field upstream. Salesforce’s own help pages now describe classic approvals as tied to specific objects with limited support for conditions.

Approval routing that falls out of sync with the business

Approval routing decides who gets each request, and it’s the part of the design most exposed to organizational change. Classic approvals can route to a user’s manager through a hierarchy field, to a specific named user, to a queue, to a user stored in a field on the record, or to someone the submitter picks manually. Every one of those options depends on data that someone has to keep current.

The Manager field is the most common source of failure. It’s often maintained by hand or synced from an HR system on a schedule that lags real changes. After a reorganization, requests route to former managers until someone updates the user records. When a manager leaves and their user is deactivated, requests assigned to them can stall until an admin reassigns them. Matrix organizations add another layer, since a rep’s line manager may not be the person with pricing authority for a given region or product.

Salesforce documents some approval routing behaviors that surprise teams at scale. According to its notes onsetting approvers, processes that let users pick an approver manually also let them pick themselves. The same article explains that when a request returns to an earlier step, the approver list for that step may not change, even if the fields that designated the approvers have changed in the meantime. It also stresses that approvers need read access to the record. An approver without access can receive the email but can’t act on the request.

Delegated approvers help, but they introduce their own drift. Users can name a delegate on their user record, and each step can allow delegates to respond. In practice, a delegate set up for a vacation 2 years ago may still hold approval rights. Good approval routing at scale treats these fields as governed data. That means each field has a clear owner and a review date on the calendar.

Record locking and the cost of waiting

Record locking protects the integrity of an approval, and it’s also one of the most common complaints from sales teams. When a record enters a Salesforce approval process, it’s locked by default. Salesforce’s guidance onediting locked records explains the 2 options: only admins can edit the pending record, or admins plus the currently assigned approver can. Nothing in the standard settings lets the submitting rep correct a typo in a field that didn’t affect the decision.

At low volume, the lock is a minor inconvenience. At higher volume, it creates a steady stream of recall-and-resubmit cycles. A rep notices a wrong close date and needs the request recalled before correcting it. The submitter can recall a classic approval request only if the process allows submitter recalls. Otherwise, an admin must recall it. Resubmitting sends the approval back to step 1. Integrations feel the lock too. A billing or CPQ sync running under an integration user without the right permissions can fail with a locked-record error, and those failures often surface hours later in an error log nobody watches closely. Locking also pushes reps to wait until every detail is final before submitting, which moves submissions toward quarter end, exactly when approvers are busiest.

Waiting time compounds across steps. Every sequential step is a handoff, and every handoff adds the time it takes the next approver to notice and respond. A 4-step chain where each approver responds within a working day still takes most of a week. Sequential chains also hide where time goes. Without step-level data, a request that took 6 days looks like a slow approval overall when it was actually 5 days of waiting at 1 step. This is the core of most approval bottlenecks: the work itself takes minutes, and the queue takes days.

Approver overload and notification gaps

Approval volume rarely spreads evenly. Most orgs route their highest-value decisions to a small group of senior leaders, and that group’s capacity doesn’t grow with the sales team. When a company doubles its rep count, the CFO and VP of Sales don’t double their review time. Their pending queue grows, and response times stretch. Approval bottlenecks at scale are often a people-capacity problem expressed through system design.

Notification gaps make overload worse. Email approval response is convenient because approvers can reply from their inbox with a single word. Salesforce’semail response limitations note that the feature doesn’t work for processes that assign approval to a queue, or for processes where, after the first step, the approver manually selects the next approver. Salesforce also documents that mobile app notifications for approval requests aren’t sent to queues or delegates. Queues are a natural choice for shared deal desk work, yet they remove 2 of the fastest response paths.

Email volume creates a quieter problem. Approvers who receive dozens of request emails a week start filtering them, and filtered requests wait until someone chases them. These problems rarely show up in testing because sandboxes don’t carry production volume. The practical response is to design for approver capacity up front. Estimate how many requests each approver will receive per week and set a response-time target for each step, with a backup path for high-volume steps. Then ask whether a senior leader needs to see every request, or only those that cross a meaningful threshold.

Discount approvals and their effect on deal speed

Discount approvals are where scale problems cost the most, because they sit directly on the path to revenue. Every day a quote waits for sign-off is a day the buyer can reopen talks with another vendor. They’re also the approvals most likely to multiply, since each new product or pricing tier tends to add another threshold and another approver. A recent McKinsey look atB2B sales playbooks lists slow approval cycles among the common symptoms of pricing processes that haven’t kept pace with the business.

McKinsey’s research on B2B pricing describes the underlying issue well. In its analysis ofsoftware deal pricing, the firm notes that every deal can look unique to managers, so approvals often rest on gut feel or on a rep’s claim that a discount is needed to win. The same piece argues that guidance works best when it arrives as reps are setting prices, before they submit the deal for sign-off. It also describes linking deal scores to approval levels, so well-priced deals approve automatically.

Complexity in pricing feeds complexity in approvals. McKinsey’ssoftware pricing research found that companies with simpler pricing and packaging were nearly 30% more likely to report effective pricing and discount controls than those with very complex structures. That finding matters for Salesforce admins because every extra bundle or add-on rule tends to create another branch in the approval logic. Simplifying the price list often removes more approval steps than any change made inside Setup. For Salesforce teams, the lesson is to settle discount policy before touching configuration. Clear discount bands and a fast path for standard deals do more for deal speed than any change to the approval steps themselves.

Automation conflicts and governor limits

A Salesforce approval process rarely runs alone. Its field updates and actions interact with record-triggered flows and Apex triggers on the same object. At low volume, those interactions work fine. At higher volume, with more automation layered on over the years, they become a common source of hard-to-trace failures.

Field updates from approval actions can cause update automation on the record to run again. If a record-triggered flow or trigger isn’t written with that in mind, it can repeat work and send duplicate notifications. Apex code that submits or approves records in bulk faces the same constraints as any other Apex. Salesforce’s documentation onApex governor limits explains that when code exceeds a limit, the platform throws a runtime exception that can’t be handled, and the transaction fails. A batch job that submits thousands of records for approval needs to be designed with those per-transaction limits in view.

Legacy automation adds risk. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025, so existing rules may keep running without bug fixes. An older Salesforce approval process often relies on those tools for surrounding field updates, and a break in that chain now has no vendor fix coming. There are also direct conflicts between approval tools. Salesforce Help notes that if a flow’s Lock Record action locks a record that’s later submitted to a classic process, the classic process overwrites that lock. It also notes that the Submit for Approval flow action works only with classic processes and can’t submit records to the flow-based version. Teams that mix old and new approval tools on the same object need a clear map of which automation owns each step.

How to find approval bottlenecks in your Org

You can’t fix approval bottlenecks you can’t see, and most orgs have more data on this than they use. Salesforce stores approval history in standard objects that admins and analysts can query. For classic approvals, ProcessInstance records the overall request while ProcessInstanceStep records each action taken. Pending requests sit in ProcessInstanceWorkitem. ProcessInstance also carries elapsed time fields that make duration analysis much simpler. For flow-based approvals, Salesforce tracks activity in Approval Submission and Approval Work Item records.

A practical diagnostic runs in this order:

Inventory every active process. List active approval processes by object, including their order and last modified date. Compare the counts against the published approval process limits and flag any object where the process list has grown past what the team can explain.

Map each routing source. Document approval routing for every step. For each one, record whether it routes to a manager field, a named user, a queue, or a record field. Named users and hand-maintained fields are the likeliest points of failure.

Measure time per step. Pull at least 2 quarters of history and calculate how long requests wait at each step. Median time shows the normal case, and the slowest requests show where deals actually stall.

Find the busiest approvers. Count pending work items by approver. When a few people hold most of the open requests, the bottleneck is capacity, and adding steps elsewhere won’t help.

Track recalls and rejection loops. A high recall rate usually means records get locked while still incomplete. Frequent rejections at the same step usually mean the entry criteria or required fields are unclear.

Check timing against the calendar. Compare submission volume by week against response times. If response times spike at quarter end, the design needs a surge plan built around fewer, faster decisions.

Share the results with the approvers before changing anything. Data on wait times helps them agree on which steps don’t earn their delay, which makes removing those steps far easier. The same data also gives you a baseline to measure any redesign against.

Classic approvals vs Flow approval processes

Salesforce’s current answer to most of the rigidity described above is its flow-based approval tool. The Salesforce Help overview ofFlow Approval Processes describes them as a way to coordinate multistep reviews that involve several people and systems. Each approval step assigns a work item to an approver, who can be a person or a shared queue. They’re built in Flow Builder from stages and Decision elements, and steps within a stage can run in sequence or at the same time. The comparison below covers the differences that matter most at scale, based on current Salesforce documentation.

Flow-based approvals never consumed orchestration runs, and Salesforce removed the separate charge for Flow Orchestration in February 2026. The Salesforce Admins team announced thatOrchestration became standard for all customers, subject to normal edition limits for Flow. The newer tool still isn’t a drop-in replacement in every case. Salesforce maintains a list of known gaps between the 2 tools, and flow-based approvals have their own constraints, such as the lack of a Loop element inside the approval process itself. For simple approvals that rarely change, a well-kept classic process can still do the job. For approvals that change often or span several teams, Flow Approval Processes are the better foundation.

How to redesign approvals for higher volume

Redesign works best when it starts with the decision and ends with the tool. Rebuilding a messy Salesforce approval process in Flow without rethinking it just moves the problem to a new screen. The choices below reduce load and clear approval bottlenecks no matter which tool you use.

Assign clear decision rights

Every approval step should have a named decision owner and a clear reason to exist. Bain’s RAPID framework is a useful reference here. Its authors argue in a piece ondecision role design that companies best at execution specify who holds each role in major decisions, covering Recommend, Agree, Perform, Input, and Decide. Mapped onto Salesforce, the “Decide” role belongs in the approval step, while people with “Input” roles can often get a notification or a review task instead of a blocking step. That single change removes many sequential handoffs.

Set thresholds that remove low-risk approvals

Most requests in a mature process are routine. Set thresholds so standard deals within approved discount bands skip review entirely, and reserve human approval for requests that cross a real risk line. Review those thresholds each quarter against actual approval data. If an approver signs off on nearly every request of a given type without changes, that step is probably adding delay without adding control.

Build routing on data you maintain

Replace hand-typed approver names with data that has an owner. Pull manager relationships from your HR system on a set schedule, and store pricing authority in a governed custom field that has a named owner. Shared work belongs in queues with clear membership. Strong approval routing at scale depends far more on data hygiene than on clever step logic. Audit delegate settings at least every 6 months.

Plan the migration in phases

Moving from classic approvals to Flow Approval Processes works best in stages. Salesforce publishesmigration considerations that list feature gaps between the tools, such as differences in how records get submitted and recalled. Review that list before committing to a timeline. A phased plan usually follows this path:

Pick 1 high-pain process with clear owners, often discount approvals on Opportunity or Quote.

Redesign the decision logic on paper with the approvers before building anything.

Build the flow version in a sandbox, including fault paths and a recall path.

Test the classic and Flow versions using separate sandbox records or controlled production cohorts. Never submit the same live record to both approval engines, since their actions and record locks can conflict. Route each new production record through only 1 version, and deactivate the classic process once its in-flight requests clear.

Update reports and dashboards to read from the new approval objects.

Repeat the cycle for the next process once the first is stable. Migrating everything at once tends to recreate the sprawl you set out to fix.

Final thoughts

Salesforce approvals break down at scale because they encode a snapshot of the company. They capture who reports to whom and what counts as risky, frozen on the day someone built the process. Classic approvals make that snapshot hard to update, so the gap between the process and the business widens with every reorg and pricing change. Platform limits exist, but most teams hit design and capacity problems well before they reach any published ceiling.

The path forward starts with measuring where requests wait and who holds them. From there, remove steps that don’t change outcomes and move routing onto data with clear owners. Then rebuild your highest-pain approvals in Flow, in sequence, with the people who approve them involved from the start. A Salesforce approval process built this way can grow with the business, because it’s designed to be changed.

Frequently asked questions

What is a Salesforce approval process?

It’s an automated sequence of steps that decides who must approve a record before it moves forward. Each step defines its approvers and entry criteria, and actions run when the record is submitted, approved, rejected, or recalled. By default, the record is locked while approval is pending.

Why do Salesforce approval processes slow down as a company grows?

Growth adds approvers and products while the approval design stays fixed. Routing fields drift out of date, and a few senior approvers end up holding most requests. Classic processes are also hard to edit once active, so outdated logic tends to stay in place.

How many steps can a classic approval process have?

A classic Salesforce approval process can have up to 30 steps, and each step can have up to 25 approvers. Both figures appear in Salesforce’s published approval process limits.

How many active approval processes can a single object have?

Salesforce allows up to 300 active classic approval processes per object and 500 in total per object. At the org level, the approval process limits are 1,000 active and 2,000 total.

Can I edit an approval process after activating it?

You can change some settings, but the list and order of steps is fixed once a classic process has been activated. That remains true even if you deactivate it. Most admins clone the process and activate the edited copy as a new version.

Why does my approval process route to the wrong person?

The usual cause is stale approval routing data, such as an outdated Manager field or a deactivated user. Process order can also be the cause, since only the first active process with matching entry criteria runs.

What happens to pending approvals when an approver leaves the company?

Requests assigned to that user can stall until an admin reassigns them. Delegates may help if they’re configured, though delegate settings often go unreviewed. Reassign open work items as part of user deactivation.

Why can’t sales reps edit a record that’s pending approval?

Submission locks the record by default. Only admins, and optionally the current approver, can edit it while approval is pending. If a rep needs a change, the approval request must be recalled. Submitters can recall a classic request only when that setting is enabled; otherwise, an admin must recall it. Resubmission starts approval again.

What are Flow Approval Processes?

They’re Salesforce’s newer approval tool, built in Flow Builder on top of Flow Orchestration. They use stages and Decision elements, and they support concurrent steps with fault paths for error handling. They arrived in the Spring ’25 release.

Do flow-based approvals cost extra?

No. Salesforce states that approvals built in Flow don’t consume automation credits or orchestration runs. Flow Orchestration itself became a standard Flow type in February 2026, subject to normal edition limits.

Should I migrate all classic approvals to Flow right away?

A phased approach works better. Start with the approval that causes the most delay. Test the new and classic versions on separate records or controlled cohorts, and keep each live record in only 1 approval process before retiring the old version.

How do I measure approval turnaround time in Salesforce?

Query the approval history objects to find approval bottlenecks by step and approver. For classic approvals, ProcessInstance and ProcessInstanceStep record each request and action, including elapsed time. For flow-based approvals, use Approval Submission and Approval Work Item records.

How can I speed up discount approvals without losing control?

Set clear discount bands so standard deals approve automatically. Reserve human review for deals that cross meaningful thresholds, and give each threshold a single decision owner.

Do Workflow Rules still affect approval processes in 2026?

They can. Many older approvals depend on Workflow Rules or Process Builder for related field updates and alerts. Salesforce ended support for both tools on December 31, 2025, so existing rules may run but won’t receive bug fixes.

Can a Salesforce approval process use a queue as the approver?

Yes, a step can assign approval to a single queue. Keep in mind that email approval response isn’t supported for queue-based steps, and mobile notifications aren’t sent to queues.