Salesforce Pricing: how Revenue Cloud calculates prices

Revenue Cloud calculates prices with Salesforce Pricing. The price book holds the list price, decision tables make pricing data readable for the engine, a context definition carries the quote line into the calculation, and a pricing procedure runs the steps in a fixed order, for example list price, volume discount, attribute discount, manual discount and aggregate price. The price waterfall then shows every step. For a manufacturer this means pricing logic becomes configuration that changes prices on every quote. I treat a pricing procedure like code: one owner, versions, and regression cases before every change.

What does Salesforce Pricing consist of?

Salesforce Pricing is the pricing part of Revenue Cloud, which Salesforce’s documentation currently also calls Revenue Management or Agentforce Revenue Management. You work in the Price Management app. According to the Trailhead unit Configure Pricing for Products1, four parts form the base:

• Price books hold the product prices. A product must be in the standard price book before it can go into a custom one, as Explore Salesforce Pricing2 explains.
• Decision tables are the bridge to the data. Pricing procedures do not read price book entries directly; rules in decision tables fetch the values from the underlying tables.
• Context definitions describe which data goes in and comes out. The default is SalesTransactionContext, which connects sales transactions to quotes, assets and orders. A pricing admin can extend it with own fields.
• Pricing procedures are the calculation itself.

On top come price adjustment schedules for volume tiers, contract prices on Contract Item Price records and derived prices3, where one product’s price follows another, such as an accessory at 10 percent of the main product’s list price.

If you come from Salesforce CPQ: what price rules and the quote calculator plugin did there has to be rebuilt in pricing procedures. Nothing is converted automatically. The other differences are in Salesforce CPQ vs Revenue Cloud.

How does a pricing procedure calculate a price?

Salesforce describes a pricing procedure as a defined set of pricing elements in an order of execution. Each element takes its input from the context definition, applies its logic and passes its output to the next element. The final output goes back to the context definition, which writes it to the quote line.

The Trailhead examples build a procedure from these elements:

1. Pricing Setting maps the line item and defines the outputs: price waterfall, net unit price and subtotal.
2. List Price looks up the price book entry by product, price book and product selling model. With “Use contract-based pricing” selected, it first looks for a contract price on the customer’s active contract4.
3. Volume Discount reads the tiers of a price adjustment schedule by quantity and effective date. The Trailhead example5 uses 10 percent from 100 units and 25 percent from 300.
4. Attribute discount adjusts the price based on product attributes, for example a cheaper version with a simpler control unit.
5. Manual Discount applies the discount a sales rep enters, by type and value.
6. Aggregate Price rolls up values from several lines6, for example per product family. It works at line level; Revenue Cloud does not roll these totals up to the quote header.

The order is business logic. Whether the manual discount comes before or after the volume discount changes the net price, and so does whether a contract price replaces the list price before volume tiers apply. Sales management and controlling decide that, not the person who builds the procedure.

A new procedure starts as an empty version V1, and each element you add becomes a step. Which procedure applies is set as the default pricing procedure in Revenue Settings. After a change you save and activate the version.

Refresh decision tables after every pricing change

This step is the easiest to forget in the first weeks. Change a price book entry or a volume tier, and the quote still calculates with the old value until the decision table has been refreshed. Trailhead shows two ways: run Sync Pricing Data in Salesforce Pricing Setup, or refresh single decision tables in Setup, such as Volume Discount Entries or, for contract prices, Contract Pricing Entries and Contract Pricing Volume Tiers.

What does the price waterfall show?

The price waterfall shows each step of the calculation from list price to final price. You see it in two places: in the simulation of the Pricing Procedure Builder, and on the quote line when you hover over the net unit price. In the contract pricing example, it shows the contract price as the base and the volume discount on top.

For sales it answers “why is the price this one?” without a ticket to IT. For controlling it documents how a price came about. For testing it is the most useful tool: the simulation has a simplified mode with input fields and an advanced mode with JSON input. Trailhead notes that developers tend to prefer the JSON mode, and I agree, because a JSON case can be stored and run again after every change.

Can other systems ask Revenue Cloud for a price?

Yes. The Salesforce Pricing Business APIs7 in the Revenue Management Developer Guide (Winter ’27, API 68.0) include resources for headless pricing, for refreshing the lookup tables and for the price waterfall.

For developers

Which Pricing Business API resources do you need?

• /connect/core-pricing/pricing for headless pricing, which builds and fills a context in one call and returns prices per line plus any errors
• /connect/core-pricing/price-contexts/{contextId} to price an existing context
• /connect/core-pricing/sync/{pricingSyncOrigin} to refresh the lookup tables
• /connect/core-pricing/waterfall resources to write and read the price waterfall of a line

This matters when the same price should appear in a dealer portal, a B2B store or an agent’s answer. The store case is covered in Advanced Pricing in B2B stores and in the chapter prices, cart and checkout. An agent should call the pricing API and never work out a price itself, the same rule I describe in Agent Script: why business rules don’t belong in the LLM.

Every pricing procedure needs one owner

A pricing procedure changes prices on every quote. I treat it like code, even though it is built by clicks:

• One owner. Usually a pricing admin in sales operations, with controlling signing off changes. The implementation partner builds, but does not decide.
• Versions. Each change becomes a new version with a short note on what changed and why.
• Regression cases. A fixed set of reference quotes with documented expected net prices: standard products, each volume tier, contract customers, attribute discounts, manual discounts above and below approval thresholds. Every change runs against all of them before it goes live.
• Deployment. Procedures move between orgs as metadata, while price books, tiers and contract prices are data. According to Gearset’s documentation8, pricing procedures are ExpressionSetDefinitions in the Metadata API, a deployment creates a new version in the target org, and the decision tables need a refresh afterwards. How this fits into a pipeline is covered in Revenue Cloud deployments.

How tests and reviews belong in the release process in general is the subject of the chapter quality, tests and reviews in the DevOps masterclass.

Worked example: pump manufacturer with dealers and contract prices

A pump manufacturer sells 60 product families through its own sales force and through dealers. List prices come from SAP into the standard price book every night. Dealers get a volume discount, 20 key accounts have contract prices for two years, and a version with a simpler control unit is 8 percent cheaper.

The procedure would contain list price with contract-based pricing, an attribute discount for the control unit, the volume discount, the manual discount and an aggregate per product family. The nightly job loads the prices and then runs the sync. The regression set has 25 reference quotes, covering each product group, each volume tier and several contract customers. When sales asks for a promotion, the pricing admin builds a new version in a sandbox, runs the 25 cases, controlling checks the differences in the waterfall, and only then is the version activated in production.

Whether SAP or Salesforce should calculate dealer and contract prices at all is a separate decision, covered in Customer prices: SAP conditions or Salesforce Pricing?.

Write down your pricing logic as steps

Write down your pricing logic as steps before anyone opens the builder: which price is the starting point, which discounts follow in which order, which ones need approval. That list becomes the procedure and the first regression cases at the same time. How pricing fits together with catalog and configurator is explained in the chapter catalog, configurator, pricing of the Revenue Cloud masterclass, and approvals in discount approvals in Revenue Cloud.

Sources8

1. 1Configure Pricing for Products (opens in a new tab)trailhead.salesforce.com
2. 2Explore Salesforce Pricing (opens in a new tab)trailhead.salesforce.com
3. 3derived prices (opens in a new tab)trailhead.salesforce.com
4. 4contract price on the customer’s active contract (opens in a new tab)trailhead.salesforce.com
5. 5Trailhead example (opens in a new tab)trailhead.salesforce.com
6. 6rolls up values from several lines (opens in a new tab)trailhead.salesforce.com
7. 7Salesforce Pricing Business APIs (opens in a new tab)developer.salesforce.com
8. 8Gearset’s documentation (opens in a new tab)docs.gearset.com