all insights

Agentforce Revenue Management: where an agent can build the quote, and where a human still signs

Revenue Cloud is now Agentforce Revenue Management, and the demo shows an agent quoting a deal in a sentence. The moment an agent quotes a price is the moment it can invent one — and in quote-to-cash, a made-up number is a contract you have to honor. Here's the real object model, how to ground the agent so it prices from the engine and never from the model, and the three places a human still has to sign.

Agentforce Revenue Management: where an agent can build the quote, and where a human still signs — article illustration

Every other agent use case can afford to be approximately right. A service agent that summarizes a case slightly loosely is still useful; a marketing agent that drafts imperfect copy gets edited. Quote-to-cash cannot afford it. The number an agent puts on a quote is a number the customer can hold you to, the discount it grants is margin off the top line, and the contract term it commits is a legal obligation. This is the one domain where “the model was mostly right” is a financial incident, not a rough edge.

Which is why the rebrand is more interesting than the usual keynote reshuffle. At Dreamforce 2025, Salesforce renamed Revenue Cloud to Agentforce Revenue Management, part of the same sweep that turned Data Cloud into Data 360 and Sales Cloud into Agentforce Sales. The name says agents now run quote-to-cash. The reality is that they can — but only if you build the guardrail that keeps the agent pricing from the engine instead of from its imagination. Get that right and the agent is genuinely useful across quoting, renewals, and billing. Get it wrong and you’ve automated the fastest path to an unhonorable quote.

What it is now, and what it used to be

The lineage matters because half the guidance online still describes the wrong product. The path runs: legacy Salesforce CPQ (the Steelbrick acquisition, a managed package bolted onto the platform with SBQQ__ objects) → Revenue CloudRevenue Cloud Advanced / Revenue Lifecycle Management (RLM)Agentforce Revenue Management today. The rename from Revenue Cloud is cosmetic — licenses and renewal dates carry over — but the shift from CPQ to RLM underneath is architectural and real.

Legacy CPQ is a managed package. RLM is native to the Salesforce core platform, API-first, with a constraint-solver-based configurator and a new pricing engine built on the platform’s own primitives. That distinction is why Salesforce set CPQ to end-of-sale in March 2025 — no new customers — with extended support running through March 2027. If you’re on classic CPQ, you’re on a platform with a clock on it, and the migration to RLM is a re-implementation, not an upgrade: there’s no magic-button converter, and CPQ Price Rules aren’t supported — pricing logic gets rebuilt as Constraint Rules and Expression Sets. Treat that as the technical-debt paydown it is, not a weekend upgrade.

The object model an agent actually touches

You cannot ground an agent on a data model you can’t name, and RLM’s model is different from the CPQ one every old blog post describes. These are standard, native objects — not SBQQ__ package objects.

Product and pricing setup. The Product Catalog (ProductCatalog, ProductCategory, Product2, ProductComponentGroup for bundles) defines what you sell. A ProductSellingModel defines how each product is sold — one-time, evergreen subscription, or term-defined subscription — and carries the term, so renewals and subscriptions are modeled at the selling-model level rather than bolted on. Pricing lives in Pricebook2/PricebookEntry with PriceAdjustmentSchedule and PriceAdjustmentTier for volume and tier discounts, plus attribute-based pricing objects for configuration-driven prices. The engine that resolves a final number is a Pricing Procedure — built from Expression Sets and Decision Tables — evaluated under the quote’s pricing context.

Transaction capture. A quote is a Quote with QuoteLineItem rows; RLM adds QuoteLineDetail to break down pricing and quantity changes, which is what makes amendments and early renewals expressible. Quotes become Order/OrderItem, orders produce Asset and AssetStatePeriod records that represent what the customer now owns, and negotiated per-contract pricing lands on ContractItemPrice under a Contract.

Billing. BillingSchedule drives when you invoice; Invoice/InvoiceLine, CreditMemo/CreditMemoLine carry the money. Note that when you invoice and when you recognize revenue are deliberately different records — a distinction that becomes the human-in-the-loop line later in this post.

Practitioners consistently warn that this model is heavy: creating a single well-formed product can touch fifteen to twenty objects, and a small change to pricing logic ripples across the whole quote-to-billing chain. That complexity is exactly why an agent helps — and exactly why the agent must never improvise inside it.

The load-bearing rule: price from the engine, never from the model

Here is the whole ballgame. When a salesperson asks the agent to “quote three hundred seats of the Pro plan on an annual term,” the agent must not reason its way to a price. A language model asked for a number will produce a plausible one, and plausible is worthless when the customer can hold you to it. The price has to come from the RLM pricing engine — the Expression Sets, Decision Tables, and discount schedules you configured — and the agent’s only job is to ask for it and read it back.

The mechanism is a custom Agentforce action — an Apex @InvocableMethod, an autolaunched Flow, or a prompt template — that invokes the RLM pricing APIs and returns the computed result. Salesforce exposes a Place Sales Transaction endpoint that creates or updates a quote or order with integrated pricing and configuration, alongside dedicated Pricing and Transaction Management business APIs that return line-level prices and the price waterfall. The agent action wraps one of those:

public with sharing class GetQuotePrice {
    public class Request {
        @InvocableVariable(required=true) public Id accountId;
        @InvocableVariable(required=true) public Id productId;
        @InvocableVariable(required=true) public Id sellingModelId;
        @InvocableVariable(required=true) public Integer quantity;
    }
    public class Result {
        @InvocableVariable public Decimal listPrice;
        @InvocableVariable public Decimal netPrice;   // engine-resolved, post-schedule
        @InvocableVariable public String  currencyIsoCode;
    }

    // The agent calls this; it never sets the number itself.
    @InvocableMethod(label='Get Quote Price'
        description='Prices a configuration via the Revenue Cloud pricing engine.')
    public static List<Result> getPrice(List<Request> requests) {
        List<Result> results = new List<Result>();
        for (Request r : requests) {
            // Delegate to the RLM Pricing / Place Sales Transaction API.
            // The Expression Sets + Decision Tables resolve the price under
            // the quote's pricing context; we only read what comes back.
            PricingService.Quote priced = PricingService.price(
                r.accountId, r.productId, r.sellingModelId, r.quantity);

            Result res = new Result();
            res.listPrice       = priced.listUnitPrice;
            res.netPrice        = priced.netUnitPrice;
            res.currencyIsoCode = priced.currencyIsoCode;
            results.add(res);
        }
        return results;
    }
}

The PricingService here stands in for the RLM Business API call; the point is the shape, not the stub. The LLM narrates — “that’s $X per seat, $Y for the year” — using values the engine produced. It never authored a digit. This is the same discipline that keeps a grounded prompt template from drifting into fiction: the model composes language around facts it retrieved, and the facts come from a system of record. If you take one thing from this post, take this: in quote-to-cash, grounding isn’t a quality nicety, it’s the difference between a quoting assistant and a liability.

What the agents actually do

With pricing safely delegated, the agent capabilities in Agentforce Revenue Management are genuinely useful, and they cluster by maturity. Treat the exact generally-available-versus-pilot label as something to confirm against the release notes for the version you’re on — Salesforce has been shipping these across the Spring ‘26 and Summer ‘26 waves and the status moves.

  • AI-assisted quoting and guided selling. The agent walks a rep (or a partner, or a customer in a self-serve flow) through configuration, and the constraint-based configurator means an invalid quote can’t be built even deliberately — the solver rejects incompatible options rather than trusting a rule to catch them. This is the most production-ready surface.
  • Renewals. Widely described as the most mature agent use case: the agent watches Asset and Contract records against their ProductSellingModel terms, flags renewals coming due, and drafts the renewal quote — with QuoteLineDetail capturing early-renewal price adjustments. More on the human line below.
  • Billing and invoicing assistance. Conversational help against the billing objects, including detecting usage or token overages and generating the upsell quote that captures them.
  • Promotions. A native promotions engine arrived in the Spring ‘26 wave for structured, configured offers.

A boundary worth drawing early: this is the transactional renewal — building and pricing the renewal quote. It is not the same job as the retention motion, where an agent watches health signals and drives a proactive save before the renewal is ever at risk. We split those deliberately in AI agents for customer success; Revenue Management builds the quote, the retention agent keeps the relationship healthy enough that the quote gets signed. Don’t collapse them into one over-eager agent.

The three places a human still signs

Agentforce runs quote-to-cash under a simple principle that Salesforce states plainly: agents move actions forward within policy that people wrote; they don’t write the policy. Three decisions are policy, and all three keep a human in the loop.

Discounts. A discount is spend authority, and it belongs in an approval process with a threshold and a named approver, exactly the way it did before agents existed — small discounts auto-approve, larger ones escalate to a manager, the largest to a VP or finance. The agent can propose a discount and submit it; it must not grant one. This is the same deterministic-gate-versus-probabilistic-hope split that runs through every decision about Flow, Apex, or Agentforce: authority is a deterministic path, never an LLM’s judgment call.

Contract terms and signature. Salesforce Contracts automates drafting, versioning, and renewal reminders, but negotiated terms and the signature are human-owned. An agent that redlines a master agreement on its own is not a feature you want.

Revenue recognition. This is the one finance will care about most, and it’s why when you invoice and when you recognize are separate records. Revenue recognition runs under ASC 606 through a finance-controlled workflow — billing schedules are not revenue schedules, and Salesforce stays the commercial system of record while journal entries go to finance for review. An agent has no business deciding when revenue is earned; it prepares the transaction, and finance recognizes it.

The rule for agentic quote-to-cash: the agent configures, prices from the engine, and drafts. A human approves the discount, signs the contract, and recognizes the revenue. Automate the assembly; never automate the authority.

The costs and the hurdles

Two practical realities decide whether this pays off. The first is that the agentic layer bills on the Agentforce consumption model — conversations or Flex Credits — on top of the Revenue Cloud license, and grounding the agent in your data typically means Data 360 is in the picture too. Build a year-one number that counts all three, not just the agent.

The second is that CPQ-class implementations are hard for reasons that have nothing to do with AI. Dirty product data, pricing logic that grew by accretion, and integrations that fail quietly are the classic failure modes, and industry commentary consistently reports that most CPQ deployments need major reconfiguration before they’re right. An agent layered on a broken product-to-cash configuration doesn’t fix any of that — it just gives the mess a conversational interface. The sequence that works is the boring one: get the catalog, the selling models, and the pricing engine correct first; ground the agent on that; and only then let it quote. There is no version of this where the agent compensates for a data model you never got right.

What to actually do

Confirm which platform you’re actually on — classic CPQ has a support clock, and RLM is the destination. Model the catalog, selling models, and pricing engine properly, because the agent inherits their quality exactly. Then wire the agent to price from the engine through a custom action that calls the RLM pricing APIs, so a quote is always a real number and never a generated one. Let the agent configure, quote, draft renewals, and flag billing overages freely — that work is reversible and high-value. And keep the three authority decisions — discount, contract, revenue recognition — behind human sign-off, enforced by approval processes and finance workflows rather than trusted to the model. Do that, and the agent earns the “Revenue Management” in its name. Skip the grounding step, and it earns you a quote you wish you hadn’t sent.

Understanding the basics

Is Agentforce Revenue Management the same as Salesforce CPQ?

No. Agentforce Revenue Management is the current name for Revenue Cloud, which is built on Revenue Lifecycle Management (RLM) — a native, API-first platform with a constraint-based configurator and a new pricing engine. Legacy Salesforce CPQ is a separate managed package (the SBQQ__ objects) that went end-of-sale in March 2025, with extended support through March 2027. Moving from CPQ to RLM is a re-implementation, not an upgrade: CPQ Price Rules aren’t supported and pricing logic is rebuilt as Constraint Rules and Expression Sets.

How do you stop an Agentforce quoting agent from inventing a price?

Never let the language model produce the number. Build a custom Agentforce action — an Apex @InvocableMethod, a Flow, or a prompt template — that calls the Revenue Cloud pricing engine through the Place Sales Transaction or Pricing business APIs and returns the engine-resolved price. The agent reads that value back to the customer and narrates around it, but the Expression Sets, Decision Tables, and discount schedules you configured are what compute it. Grounding the price in the system of record is the core guardrail for agentic quote-to-cash.

What can an Agentforce revenue agent do without human approval?

It can configure a quote, price it from the engine, draft renewal quotes, flag renewals and billing overages, and prepare transactions — all reversible, low-risk work. It should not autonomously grant a discount, finalize or sign a contract, or decide revenue recognition. Those three are authority decisions: discounts run through an approval process with a threshold and approver, contract terms and signature stay human-owned, and revenue recognition runs under ASC 606 through a finance-controlled workflow. The agent proposes; a human signs.


Sitting on classic CPQ and weighing the move to Agentforce Revenue Management — or trying to put an agent on quote-to-cash without it inventing prices? Talk to us. Getting the pricing engine and the grounding right so the agent quotes reality is exactly the work we do.

Keep reading

All insights