- Most organisations over-engineer pricing approval. Native Salesforce approval processes handle the majority of use cases without any additional tooling or cost.
- CPQ tools are justified when your quoting process is complex. They are not justified for discount governance on a straightforward product set.
- Pricing approval audit trails have downstream commercial and legal significance.
- Before evaluating any tool: write your approval trigger conditions, approval chain, and approver roles on one page.
The requirement lands clearly: every pricing proposal above a certain discount threshold needs to go through an approval process before it reaches the customer. Approvals need to be logged, decisions need to be traceable, and the sales team needs to be able to submit and track approvals without leaving their CRM workflow.
The question of how to implement this — native configuration, AppExchange tool, custom module, or standalone CPQ — is one where the default choice is often more complex and more expensive than the situation requires. The right starting point is not which tool to evaluate but which requirements actually apply to your situation. Most pricing approval needs are simpler than they initially appear, and most implementations add more complexity than they need to carry.
What Pricing Approval Actually Requires — and What It Usually Doesn't
Before evaluating options, distinguish between the requirements your approval process genuinely has and the requirements that get added because they sound like good ideas. These two categories have different implications for which solution is appropriate.
Requirements most approval processes actually have:A trigger condition — discount above a threshold, deal size above a value, specific product combinations. A defined approver or approval chain. A notification mechanism — the approver needs to know a request is waiting. An audit trail — a record of who approved what, when, and at what price. An outcome that affects the deal — approved proposals can proceed, rejected ones cannot without revision.
Requirements that get added but often aren't necessary:Complex multi-level conditional routing based on deal characteristics. Integration with ERP or finance systems for revenue recognition. Automated contract generation triggered by approval. Parallel approval tracks for legal, finance, and sales leadership simultaneously. Real-time margin calculation during the approval request. Custom approval portals accessible outside Salesforce.
The first set of requirements is handled cleanly by Salesforce's native approval process engine. The second set starts to push beyond what native configuration can do well — and that is where the case for additional tooling begins to exist. The mistake most organisations make is assuming they need the second set before they have validated that assumption.
Option 1 — Native Salesforce Approval Processes
What this coversSalesforce has a built-in approval process engine that has been part of the platform since its early versions. It supports multi-step approvals, conditional entry criteria, multiple approvers at each step, parallel approval tracks, email and Chatter notifications, and a complete audit history of every approval decision. It is configurable entirely by an admin — no Apex code required for the majority of use cases.
What it does wellFor a pricing approval process with a defined trigger, one to three approval levels, and a standard notification requirement, native Salesforce approval processes are genuinely sufficient. They are part of the platform you are already paying for, require no integration maintenance, store approval history natively in the record, and work on any object — Opportunity, Quote, custom object — without additional configuration. The audit trail is automatic and complete: every approval request, every delegate action, every approval or rejection is logged with a timestamp and the approver's identity.
Where the limits appearThree scenarios push native approvals toward their limits. First, highly conditional routing — if your approval chain changes significantly based on combinations of deal characteristics (discount percentage AND product family AND customer segment AND territory), native approval process logic becomes difficult to maintain as conditions multiply. Second, dynamic approver assignment — if the approver is not a fixed role but needs to be calculated based on deal attributes at submission time, native approvals require workarounds that increase complexity. Third, approval requests that need to be initiated, reviewed, or acted on entirely outside Salesforce — by approvers who do not have Salesforce licences, for example.
Total cost of ownershipLow. No additional licence cost. Admin time to configure and maintain. The primary ongoing cost is admin capacity when the approval logic needs to change — which it will, as your discount policy evolves.
Option 2 — AppExchange CPQ and Approval Tools
What this coversThe Salesforce AppExchange has a substantial ecosystem of Configure-Price-Quote (CPQ) tools — Salesforce's own CPQ product (formerly Steelbrick), as well as third-party tools like DealHub, PandaDoc, Conga, and others — that handle pricing approval as part of a broader quote-to-cash workflow. There are also lighter approval-specific tools that add capability to the native engine without the full CPQ overhead.
When CPQ is the right answerCPQ is justified when your pricing approval requirement is inseparable from a more complex quoting problem: a large product catalogue with complex pricing rules, bundling logic, volume discounts, and configuration constraints that need to be enforced before a quote reaches the approval stage. In this context, the approval workflow is one component of a system that is solving a genuinely hard problem — and a standalone approval configuration would sit on top of a broken quoting process rather than fixing it.
If your quoting process is straightforward — a defined set of products with standard pricing and a discount approval threshold — CPQ is not the right answer for your approval requirement. You are buying a significantly more expensive and complex system to solve a problem that native Salesforce handles.
The Salesforce CPQ consideration specificallySalesforce CPQ is deeply integrated with the platform and eliminates many of the sync reliability concerns that apply to third-party AppExchange tools. But it is expensive — plan for meaningful per-user licence costs on top of your existing Salesforce contract — and it requires dedicated admin expertise to configure and maintain. The implementation timeline for a meaningful CPQ deployment is typically three to six months. If your approval requirement is primarily about discount governance rather than complex quoting, that investment is disproportionate.
Data and integration considerationsThird-party CPQ tools that sit outside Salesforce but integrate with it carry the same sync reliability risks described in the account research module article. The sync that works at deployment degrades over time as both platforms update. Approval records stored in the external tool may not be fully reflected in Salesforce, creating audit trail gaps that become significant during finance reviews or compliance audits.
Total cost of ownershipHigh for full CPQ. Salesforce CPQ licences, implementation costs, and ongoing admin expertise make this a significant investment. Lighter AppExchange approval tools are cheaper but still carry integration maintenance overhead. Neither is appropriate if your requirement is straightforward.
Option 3 — Custom Module Inside Salesforce
What this coversBuilding a custom approval workflow using Apex code, Flow, Process Builder, or Lightning Web Components — creating a bespoke system that handles approval logic that native Salesforce cannot manage through configuration alone.
When it is justifiedGenuinely complex conditional routing that native approval processes cannot express cleanly. Dynamic approver calculation based on multiple deal attributes. Custom approval interfaces — for example, a bespoke approval dashboard for sales leadership showing all pending approvals across their team with deal context. Integration with a finance or ERP system that needs to receive approval outcomes in a specific format.
The maintenance realityCustom Apex code for approval workflows is among the more maintenance-intensive categories of Salesforce customisation. Approval logic frequently changes as discount policy evolves — every policy change requires a code change and a deployment. Salesforce's three annual platform releases can break custom Flow and Process Builder logic, particularly in major release cycles. If you build a custom approval module, budget for a Salesforce developer to review and test it against each major release — not as a contingency, as a planned recurring cost.
One specific risk worth calling out: Salesforce has been deprecating older automation tools in favour of Flow. If your custom approval module was built using Process Builder or Workflow Rules — both of which Salesforce has announced end-of-life plans for — you are carrying technical debt that will need to be rebuilt into Flow regardless of whether your requirements change.
Total cost of ownershipHigh upfront, medium ongoing if you have internal Salesforce development capacity. Without it, agency costs for maintenance and policy-change deployments accumulate quickly.
Option 4 — Custom CRM with Native Approval Module
What this coversBuilding a pricing approval workflow as part of a fully custom CRM — either as one module among many in a bespoke system, or as the primary justification for moving away from Salesforce entirely.
When the approval requirement alone justifies thisIt almost never does. A pricing approval requirement — even a complex one — is not sufficient justification for a custom CRM build. The approval workflow is one process within a broader sales system that also handles pipeline management, forecasting, activity tracking, reporting, and a dozen other functions. Building or moving to a custom CRM to solve an approval problem you could have solved with native Salesforce configuration means accepting the full cost and complexity of a custom CRM to avoid a configuration effort that would have taken days.
The scenario where this makes sense is when the approval requirement is symptomatic of broader inadequacy — when Salesforce is failing across multiple dimensions and the approval complexity is one of several reasons you are evaluating alternatives. In that context, the approval capability of a custom CRM is one factor in a broader platform decision, not the driving one. If your primary frustration is specifically the approval workflow, the right question is whether you have fully explored what native Salesforce can do before concluding it is inadequate.
Total cost of ownershipVery high. The same considerations apply as in the account research article: a custom CRM is a product, not a project, and the ongoing engineering commitment is substantially underestimated in most build decisions.
The Audit Trail Requirement Deserves Special Attention
Pricing approval audit trails are different from other workflow audit requirements because they have downstream commercial and sometimes legal significance. An approval record is evidence that a discount was authorised by the right person at the right level — it may be relevant in a customer dispute, an internal audit, a finance review, or a regulatory examination depending on your industry.
This has two practical implications for your solution choice. First, wherever your approval records live, they need to be immutable — the record of an approval decision should not be editable after the fact. Native Salesforce approval history is immutable by design. External tools that store approval records in their own system may have different data retention and immutability guarantees. Check this explicitly, not by assumption.
Second, the audit trail needs to be accessible to the people who will need it — finance, legal, compliance — without requiring them to access Salesforce directly or to contact RevOps for a data export. If your approval records are buried in Salesforce in a way that is hard to retrieve for a non-Salesforce user, that is a reporting and access problem worth solving alongside the approval workflow itself.
The Decision Framework
| Your situation | Right option | Why |
|---|---|---|
| Simple trigger, 1–3 approval levels, fixed approvers | Native Salesforce approval process | Fully sufficient, no additional cost, complete audit trail built in. Explore this thoroughly before looking elsewhere. |
| Complex quoting with bundling, configuration rules, volume pricing | Salesforce CPQ or third-party CPQ | Approval is one component of a quoting problem that needs end-to-end solving. CPQ investment is justified by the quoting complexity, not the approval alone. |
| Highly conditional routing or dynamic approver assignment | Custom Salesforce module (Flow) | Native approval logic cannot express complex conditions cleanly. Build in Flow rather than Apex where possible to reduce future migration risk. |
| Approvers without Salesforce licences need to act on requests | AppExchange approval tool or custom module with email-based approval | Native Salesforce approval email actions allow approvers to approve/reject via email without a Salesforce login — explore this before buying a tool. |
| ERP or finance system needs approval outcomes in real time | Custom module with API integration or iPaaS middleware | Native approvals can trigger outbound API calls via Flow. Evaluate whether a middleware layer (MuleSoft, Workato, Zapier) is sufficient before building custom. |
| Salesforce is inadequate across multiple dimensions | Platform evaluation including custom CRM | The approval requirement is one signal in a broader platform decision. Evaluate it as part of the whole, not as the driver. |
1. Have you built and tested a native Salesforce approval process for your actual use case? Not evaluated it theoretically — built it in a sandbox and walked your team through it. Most organisations discover native Salesforce is sufficient at this stage. Most skip this stage and go straight to vendor evaluations.
2. What are your approval trigger conditions, approval levels, and approver roles — written down specifically? "It's complex" is not a specification. Write out every condition under which an approval is required, who approves at each level, and what the outcome is for each decision. This document will reveal whether your process is genuinely complex or complex-feeling because it has never been written down clearly.
3. Who needs to see the audit trail, how often, and in what format? Finance quarterly? Legal on request? Compliance annually? The answer determines whether Salesforce's native reporting is sufficient or whether you need a separate reporting layer.
4. Do any of your approvers lack Salesforce licences? If yes, note that native Salesforce approval processes support email-based approval actions — approvers can approve or reject via email reply without logging into Salesforce. Evaluate this before concluding that an external tool is required.
The Recommendation for Most Sales Teams
Start with native Salesforce. Configure it for your actual use case — not a theoretical future use case — and run it for 90 days. The most common outcome is that it is sufficient. The second most common outcome is that it surfaces specific gaps that you can now specify precisely and solve in the most targeted way — rather than buying a broad platform to solve a problem you had not fully defined.
The organisations that end up with over-engineered approval systems are almost universally the ones that began evaluating tools before specifying requirements. The organisations that end up with appropriate solutions are the ones that wrote down exactly what they needed, tested the simplest option first, and escalated complexity only when the simpler option demonstrably failed.
Pricing approval is a governance problem before it is a technology problem. The technology should enforce the governance policy your business has defined. If your governance policy is not clearly defined — if there is ambiguity about who approves what at which threshold — no tool will fix that. Define the policy first. Then configure the simplest tool that can enforce it.