Salesforce CPQ: when to choose native, integrated, or customised?

Choosing a CPQ — Configure, Price, Quote, or configuring, pricing and quoting — means deciding where the rules that turn an opportunity into an executable proposal reside. Consider Salesforce's current offering when centralizing the catalog, commercial rules, and channels is the priority, as long as your products, volumes, and contracts undergo a proof of concept. Being on the platform alone does not prove fit.

A third party running on the Salesforce platform deserves consideration when it provides a specific capability that justifies another supplier. A external engine makes sense when the ERP (enterprise resource planning system) or a specialized configurator must remain the authority for configuration and pricing, including for other channels. On the other hand, the limited customisation serves an isolatable rule, with an owner, version, and tests — not as a shortcut to rebuild the entire CPQ.

It is also valid to continue temporarily with legacy Salesforce CPQ when it serves the operation, remains covered by contract and an immediate switch would bring more risk than benefit. Salesforce states that the product is in end-of-sale, not end-of-life, and that there is no forced migration (official position on the legacy product). The decision should compare fit, continuity, and cost, not start from an assumed shutdown.

Salesforce CPQ, Revenue Cloud, and Agentforce: what each name means

O legacy Salesforce CPQ is a managed package. The product documentation states that it remains available to existing customers, without development of new features, with the possibility to renew subscriptions, add licences and receive support during the contract. This does not constitute a promise of perpetual support. On 09/09/2026, the cited official sources do not give a public product end-of-life date.

The other names need to be distinguished:

• Revenue Cloud Advanced: is presented by Salesforce as the successor to Salesforce CPQ and part of the Agentforce Revenue Management suite. Its architecture differs from that of the legacy package; therefore, the transition should not be budgeted as a simple version upgrade (official explanation).
• Revenue Cloud and Agentforce Revenue Management: your Trailhead states that Revenue Cloud was renamed Agentforce Revenue Management. References to the previous name may still appear in the application and documentation. The suite covers catalog, CPQ, contracts, assets, orders, billing, subscriptions, and consumption.
• Agentforce for Revenue: was the name used in the announcement of the agent solution embedded in what was then Revenue Cloud. It is not synonymous with the legacy Salesforce CPQ package, nor is it a precise way to identify the entire current suite by itself.

When purchasing, record the product, edition, components, and usage rights. A broad commercial name does not determine which features will be available in your environment.

Native versus integrated CPQ: compare four architectures

"Native" can mean Salesforce product or third-party product built to run on the Salesforce platform. These are different situations: they change the vendor, support responsibility, data model, and evolution process.

Conga itself Conga presents products with different topologies: Advantage CPQ as Salesforce-native and Smart CPQ as CRM-agnostic. The example shows why assessment must be done product by product, not just by brand.

Architecture	Execution and data	Implication for the decision
Salesforce's current offering	Runs on the platform, using the model of the purchased components. Authority over the catalogue and pricing must be defined alongside existing systems.	Assess the concentration of the sales cycle. Eliminate it if essential rules require structural duplication or adaptations that are difficult to maintain.
Third party on the platform	Runs on the platform, but may use its own objects, rules and contract cycles.	Assess differentiating capability. Eliminate it if the model, export, limits, or responsibility for failures between suppliers are unclear.
Integrated external engine	Configures or calculates outside Salesforce. Salesforce, as the CRM (customer relationship management system), keeps references and states synchronised with the external authority.	Preserves specialisation and service across multiple channels. Eliminate it if latency, unavailability, or reconciliation make the sale unviable.
Bounded custom extension	Implements a specific rule in Flow, Apex, or an external service without taking on the full CPQ cycle.	It addresses a localized gap. Eliminate it if the extension turns into a second catalog, pricing engine, or contract manager.

Running on the same platform does not guarantee automatically sharing objects, lifecycle or source of truth. For any product, require documentation of the data model, integration interfaces, limits, updates, export, and support.

In an extension, the choice between Flow, Apex and an external service depends on complexity, volume, transaction and maintainability. The team needs to be able to change a rule without rediscovering how the whole process works with every change.

Governance also cuts across all four options: those who publish prices should not, as a consequence, gain unrestricted freedom to approve discounts. Those who maintain the integration need to see the failure without receiving unnecessary access to commercial data.

Design the path from quote to ERP

Before the demonstration, map a complete operation:

Catalogue → configuration → price → approval → contract → order → ERP → billing and tax document.

For each step, name the system that can create or change the information. This is the source of truth: the authority defined for that data, not necessarily a single system for the entire company.

The catalog may have technical attributes maintained in a product information management system and commercial conditions maintained in CPQ. In that case, identifiers, versions, and effective dates need to connect the two. Copying everything without defining precedence creates discrepancies that are difficult to diagnose.

When pricing, record quantity, currency, term, recurrence, and negotiated conditions. Approval must be tied to the proposal version. If a salesperson changes items or conditions after internal approval, the design must determine when to recalculate and request new approval.

Contract, order and contracted asset also need clear links. A renewal cannot depend only on the current catalogue: it needs to consider what the customer actually contracted and which changes were accepted.

A Salesforce's current offering announces catalog, pricing, contracts, assets, orders, and billing, but it also includes integrations with ERP and product systems. Therefore, there is no basis for promising no integration or a single model across the architecture.

Where Agentforce fits in

A current CPQ page announces configuration through rules and constraints, configurable approvals, and assisted quoting with role-based permissions. These are capabilities announced for the current offering, not functional documentation for the legacy package.

The agent can help prepare or update a quote, but does not replace pricing policy, approval, or segregation of duties. The existence of a feature in sales material does not prove that it will work with your catalogue, permissions and licensing. This needs to be demonstrated. To better understand what these agents do and where their limits are, see the guide to Agentforce: what it is and how AI agents work in Salesforce — use it as navigation context, not as proof of CPQ fit.

For integrations, it is worth adopting traceable identifiers, retry handling without duplication — known as idempotency — and error monitoring. These patterns are covered in greater depth in the guide to Salesforce integrations.

Hypothetical example: a proposal and an architectural choice

Imagine a company that sells equipment with a monitoring subscription. Its specialised configurator already serves salespeople and distributors, while the ERP keeps the technical configuration accepted for production.

A hypothetical proposal contains:

• 30 pieces of equipment at R$2,000: R$ 60,000;
• 30 subscriptions at R$ 100 per month, for 24 months: R$72,000;
• installation: R$10,000.

The commercial commitment totals R$142,000, before variable consumption and without a tax simulation. This does not mean a one-off charge of that amount.

The salesperson requests an 8% discount on equipment only. The discount is R$ 4,800, and the commitment becomes R$ 137,200. In this scenario, the policy requires management approval above 5%. An agent can prepare the proposal, but the new version should not proceed as approved before that authorization.

Now suppose an accessory is incompatible with the selected equipment. The configurator must prevent the combination before it reaches production.

The initial choice would be to retain the specialised external engine, if the proof of concept demonstrates adequate response, blocking of invalid combinations, and failure recovery. Salesforce would centralise the commercial interaction and quote references without duplicating the authoritative calculation.

The consequence is accepting an operational dependency on the integration. If the engine is unavailable, the proposal cannot be presented as validated: the flow needs to preserve the draft and show its pending status. In exchange, the company avoids maintaining two versions of the same technical rule.

Salesforce's offering would become preferable if it demonstrated the same fit and made it possible to retire the existing engine with an economic benefit. Without that evidence, replacing the specialization solely to reduce the apparent number of systems would be a gamble.

Brazil: commercial pricing is not tax calculation or tax-document issuance

A CPQ architecture for Brazil needs to separate four responsibilities. This separation is a technical recommendation, not a requirement to have four vendors:

• CPQ: defines configuration, commercial price, discounts and negotiated terms.
• ERP or tax engine: determines tax treatment according to the transaction, records, and applicable rules.
• Billing (billing): organises amounts to charge, service periods, due dates and adjustments.
• Tax document issuer: generates and transmits the document and tracks applicable returns and events, such as authorisation, rejection, and cancellation.

The electronic invoice (NF-e) and the Electronic Service Invoice (NFS-e) has different rules and layouts. The document choice depends on the nature of the transaction and applicable legislation; it should not arise from a simplified commercial classification within CPQ.

The Brazilian Federal Revenue Service guidance for 2026 addresses the itemised disclosure of the Tax on Goods and Services (IBS) and the Contribution on Goods and Services (CBS), according to the rules and layouts of each document. The exemption from collection mentioned for 2026 is conditional on complying with current regulations: it is not an exemption from adapting the documents.

Obligation, layout, and rejection are different things

As of 09/09/2026: your Joint Act RFB/CGIBS No. 4 sets milestones by document and transaction category — not a universal date. For NF-e model 55, the general milestone addressed by the act is 03/08/2026, but Article 1, paragraphs 1 to 4, itself provides exceptions: taxpayers under Simples Nacional, transactions subject to single-phase taxation, and import transactions have their own milestones in 2027, while non-ICMS taxpayers carrying out the covered transactions enter on 01/12/2026. For NFS-e, 01/10/2026 applies to services also subject to ISS outside items "a" to "c"; the categories listed in the remaining items enter on 01/12/2026, and Simples Nacional follows the treatment of Article 1, paragraph 1. None of these dates should be read as a single deadline for completing any field in any transaction or regime.

In NF-e/NFC-e, the Technical Note 2025.002-RTC, version 1.51 documents fields and rules for IBS, CBS, and Selective Tax. Its schedule distinguishes approval testing, production, legal requirement, and the activation of validations. The presence of a field in the layout is not enough to determine whether it is required for any given transaction.

In the national-standard NFS-e, the official guidance on IBS/CBS deadlines states that omitting these taxes until 31/12/2026 does not cause rejection by the national system, but may leave the document non-compliant depending on its classification. The absence of a rejection does not prove tax compliance.

In addition, the NFS-e Technical Note 009 sets out a separate implementation schedule. Its publication does not mean full availability in production, a distinction also present in the official NFS-e technical documentation.

For the project, the tax department's concrete deliverable should be an approved mapping of operation, regime, document, tax classification and applicable rule. Architecture must preserve these identifiers and the calculation version across quotation, order and issuance. None of the cited CPQ sales pages alone proves complete Brazilian tax localisation.

A short proof of concept with disqualifying evidence

The proof of concept (PoC) must use representative data and expected results defined before execution. It is not enough to follow an ideal path prepared by the supplier.

Select the applicable cases below and record product version, configuration, inputs, outputs, and failures:

1. Invalid product combination: attempt an incompatible set. Evidence: an explainable block, without relying on subsequent manual correction.
2. Recurrence and consumption: combine one-off billing, monthly fees, and variable consumption. Evidence: reproducible calculation record, with agreed validity periods and rounding.
3. Discount outside authority: request an exception and change the proposal after approval. Evidence: version history and blocking or reapproval according to policy, including through an agent or integration.
4. Existing contract renewal: renewing or changing an asset under conditions different from the current catalogue. Evidence: preservation of expected rights and values.
5. Representative volume: run large quotes and concurrent access. Evidence: times and errors measured against limits defined by the business, without accepting generic scale promises.
6. Integration failure and retry: interrupt communication after processing at the destination. Evidence: recovery without creating a duplicate order or charge.
7. Commercial reconciliation: track the same transaction from proposal to billing. Evidence: reconcilable quantities, versions, and values, with justification for legitimate differences.
8. Applicable tax document: follow the integration through to the corresponding test environment. Evidence: content compliant with the approved layout and classification, as well as return handling.

If a mandatory case fails, record the proposed correction, its owner and the support cost before retaining the alternative in the comparison. Distinguishing 'it worked', 'it is documented' and 'it depends on development' prevents hiring a hypothesis as if it were a delivered capability.

Compare total cost over 36 months

Total cost of ownership, or TCO, requires a common horizon. Here, 36 months from the decision is a comparison criterion, not a market average or an empirical forecast of project duration.

The calculation must include:

• Procurement: licences, additional modules, environments, and artificial intelligence consumption, where applicable.
• Transition: implementation, data cleansing and migration, integrations, testing, and training.
• Operations: administration, monitoring, support, rule maintenance and regression after updates.
• Exit: export, replacement of extensions, contract termination, and potential parallel operation.

Use the same functional scope and volumes across the alternatives. A proposal that excludes renewals, tax requirements, or integration support is not necessarily cheaper: it may be incomplete.

Also estimate internal work. An extension without additional licence may consume development, testing and incident-service hours. The third party on the platform may require coordination between suppliers. An external engine may preserve an investment but add observability and recovery costs.

To remain on the legacy solution, include support and the cost of deferring relevant requirements. If migration is planned within the time horizon, include it in the calculation. Significant costs after 36 months must be explicit, not made to disappear for convenience.

Also compare growth scenarios for users, quote volume, consumption, and contractual changes. Values that depend on assumptions should be presented as estimates, not guaranteed savings. The guide to Salesforce costs complements the discussion of investment composition.

Decide with a continuity plan

The chosen alternative must pass the eliminatory requirements and offer the best balance of cost, risk, and capacity to evolve. The lowest TCO among solutions that do not meet operational needs does not solve the problem.

If the decision is to migrate, start with a controlled subset of products or a channel. Reconcile contracts, assets and open proposals before the change. Define how to conclude transactions initiated in the previous system and under which conditions to stop or reverse the transition. The timeline follows these dependencies, not a generic market range.

If the decision is to remain temporarily on the legacy product, record the reassessment triggers: an unmet new requirement, deteriorating support, rising cost, or a relevant contractual change. Staying can be a conscious decision; staying without criteria merely postpones the choice.

The expected result is not "having the newest CPQ." It is being able to explain who controls each rule, demonstrate that the operation works, and know the cost of maintaining and changing it.

Need to compare these alternatives in your scenario? Talk to WeeNow about a CPQ architecture assessment.