Most teams implementing Salesforce Revenue Cloud discover usage-based products early — anchor subscriptions with token allowances, overage charges, rate cards. What fewer teams ever touch is the commit product family: Token Commits, Monetary Commits (Commitment Spend), and Quantity Commits. These are the products that let your customer lock in a committed consumption volume in exchange for a discounted rate — and they are one of the most misunderstood corners of Revenue Cloud.
This article unpacks all three commit flavors using a running Robotics Inc. scenario — a fictional robotics platform company that sells AI compute to industrial customers. By the end you will understand when to use each commit type, what records you need to build, and why the list price on the quote line almost never matches the math of the discount percentages.
What You Will Learn
- The three
UsageModelTypecommit values and when each one fits - The shared data model every commit product follows — PUR, PUG, Rate Card, Policies
- Three pricing patterns for token commits: EACH, FLAT, and TIER
- Why the commit line list price is independent from the rate card math
- The non-obvious gotchas that waste days of implementation time
The Robotics Inc. Use Case
Meet Robotics Inc., a cloud platform that sells AI workloads to industrial customers. Their flagship product — the Robotics AI Platform — is a tokenized anchor subscription. Customers subscribe for $24,000 a year, and consumption of Compute Time and Data Storage is metered and converted to AI Tokens before being billed at $1.00 per token. A small allowance of 100,000 tokens is bundled with the anchor.
As deals scale, Robotics Inc. sales reps hear the same pushback: “We will probably use around a million tokens — can we get a better rate if we commit upfront?” The answer is yes, and the mechanism is a commit product. The anchor and the commit sit side by side on the quote, the customer prepays for 1,000,000 tokens at a negotiated $0.75 per token ($750,000 total), and consumption draws down the committed bank at the discounted rate until it runs out.
Note: The commit product is a separate Product2 record from the anchor. It has its own PricebookEntry, its own rate card, and its own line on the quote. What makes it a “commit” is the UsageModelType field value, not the pricing itself.
The Three Commit Flavors
Revenue Cloud exposes commit products through three distinct UsageModelType picklist values. Each commits to a different thing, uses a different resource category, and fits a different sales conversation.
| UsageModelType | Commits To | Resource Category | Sales Conversation |
Commit | A quantity of tokens | Token | “Lock in N tokens at a discount — use them any way you want” |
CommitmentSpend | A monetary amount | Currency | “Prepay $X of consumption at a discount” |
CommitmentQuantity | A specific resource quantity | Usage (directly) | “Commit to N TB of storage OR N hours of compute at a discount” |
Token Commit (UsageModelType=Commit)
The most flexible option. The customer commits to a token bank — a pool of abstract units — and any anchor resource that converts to tokens (via TokenResourceId on its PURs) draws from the same bank. This is what Robotics Inc. offers: one commit product that discounts token consumption regardless of whether the customer burns tokens on compute, storage, or future resources not yet launched.
The key records:
- One
UsageResourcewithCategory=Token(shared with the anchor) - A
ProductUsageResource(PUR) on the commit product for that Token resource - A
ProductUsageGrant(PUG) on that PUR withType=CommitandQuantity=1,000,000 - A Tier rate card with a
RateCardEntryon the Token resource and a percentage discount
Monetary Commit (UsageModelType=CommitmentSpend)
When the customer wants to commit a dollar amount instead of a token count, use CommitmentSpend. The commit PUG lives on a Currency-category UsageResource (for example “USD Resource”) with Type=Commit and Quantity=5000 — meaning $5,000 committed.
There is a specific constraint here: you cannot create a RateCardEntry on a Currency-category resource. Revenue Cloud blocks it. That means the discount percentage applied to consumption lives on RCEs for the Usage resources (Compute Time, Data Storage), not on the Currency resource itself. The Currency resource only carries the committed dollar amount on its PUG.
Quantity Commit (UsageModelType=CommitmentQuantity)
The narrowest of the three. The customer commits to a specific quantity of a specific resource — 1,000 TB of Data Storage or 1,000 hours of Compute Time — and the discount only applies to that resource. If you want independent commitments across multiple resources, you put one Commit PUG per resource directly on the commit product, each with its own discount percentage.
There is no Token resource and no Currency resource in a Quantity Commit. The Usage resource itself carries the commit.
The Shared Data Model Every Commit Follows
Here is the trap teams fall into: they think a commit product is a stripped-down usage product with only one commit PUG on one resource. It is not. Every commit product mirrors the anchor’s full resource structure, just with different PUG types and a different rate card strategy.
Concretely, for Robotics Inc.’s Token Commit you need:
- Three PURs: Compute Time (Usage), Data Storage (Usage), AI Tokens (Token). Compute and Storage PURs carry
TokenResourceId=AI Tokensjust like on the anchor. - Three PUGs: one Grant-type PUG each for Compute (Qty=0) and Storage (Qty=0), plus a Commit-type PUG for AI Tokens (Qty=1,000,000).
- One PricebookEntry: list price $750,000 on the Standard Price Book, linked to the same Term Annual selling model as the anchor.
- A Tier rate card with one or more RCEs providing the discount adjustment (we will cover the three patterns next).
- Policies: a
UsageCommitmentPolicy(typically “Lowest Commitment Rate”), aUsageOveragePolicy, and Product Usage Resource Policies (PURPs) per PUR linking the commit policy to the resource.
Important: You cannot attach a UsagePrdGrantBindingPolicy to a commit product. Revenue Cloud blocks the insert with “Select a Product with the Usage Model Type as Anchor or Pack.” That is the design-time binding; commits bind at runtime through UsageCommitmentAssetRelatedObject records after the order is activated.
Three Ways to Price a Token Commit: EACH, FLAT, TIER
Once you have the skeleton above, the rate card is what makes a commit feel different. There are three clean patterns, each using a Tier-type rate card but expressing the discount differently. Which one you pick depends on how the customer wants to negotiate and how your pricing team wants to model the math.
Pattern 1 — EACH: per-resource percentage discount
Three RCEs on the commit’s Tier rate card, one per resource (Compute Time, Data Storage, AI Tokens). Each RCE has its own RateAdjustmentByTier record with a single tier (LB=0, UB=null) and its own percentage. All three use RateUnitOfMeasure=TOKEN.
Use EACH when different resources justify different discount levels — for example Compute Time gets 5% off, Data Storage gets 4% off, and the AI Tokens conversion gets 6% off. You can also set a non-zero Grant quantity on the Usage resources to include free units during the commit period.
Pattern 2 — FLAT: cross-resource flat discount
Two RCEs. The first has UsageResource=NULL — yes, the foreign key is nullable — and a single RateAdjustmentByTier with Percentage 10. Because there is no specific resource attached, this RCE applies the 10% discount uniformly to every Usage resource consumed under the commit. The second RCE sits on the Token resource itself with RateUnitOfMeasure=USD at 0% and simply carries the token-to-dollar conversion through.
Use FLAT when the commercial story is one round number — “10% off everything when you commit a million tokens.” It is the cleanest pattern for the sales rep to explain and the simplest to model.
Pattern 3 — TIER: volume-tiered percentage discount
Same structure as FLAT — one RCE with UsageResource=NULL — but the RateAdjustmentByTier has multiple rows with different bounds and different percentages.
| LowerBound | UpperBound | Discount |
| 0 | 1,000 | 10% |
| 1,000 | 5,000 | 20% |
| 5,000 | null | 30% |
Use TIER when the customer wants bigger discounts as they consume more — a growth-oriented discount schedule that rewards higher usage. The engine applies the tier that corresponds to the cumulative consumption volume within the commit period.
Note: Older Salesforce documentation says commit RCEs can only have a single tier with LB=0 and UB=null. Production reference implementations prove otherwise — multi-tier commit discounts are fully supported as long as you set UsageResource to null on the RCE.
Why the Quote Line Total Does Not Match the Rate Card
Here is the single most confusing thing about commit products, and the reason so many early implementations get stuck. The PricebookEntry.UnitPrice on a commit product and the RateAdjustmentByTier percentage on its rate card are two independent things.
Revenue Cloud does not automatically compute the PBE price from (commit quantity × effective rate). That number is a manually negotiated figure that represents what the customer actually pays for the commit subscription. The rate card only controls how consumption is rated against the committed bank.
Robotics Inc.’s math happens to balance — 1,000,000 tokens × $0.75/token = $750,000 list price, with a 25% discount off the anchor’s $1.00/token list rate. But there is nothing in Revenue Cloud forcing that alignment. You could perfectly legally have a $500 list price on a 1,000 TB Data Storage commit with a 20% discount, because:
- The $500 is the reservation fee the customer pays to lock in the commit slot
- The 20% is the rate on consumption when usage hits the committed bucket
- These are commercial negotiation points that do not have to reconcile mathematically
Sales ops teams should negotiate both numbers deliberately. If you want the quote to be defensible — “you committed $X for $Y of discounted usage” — align them yourself. Revenue Cloud will not check your math.
The Percentage vs Override Trap
When you build a commit rate card, RateAdjustmentByTier.AdjustmentType offers three values: Percentage, Amount, and Override. Picking the wrong one produces a product that works in the rating engine but renders as empty rows in the Manage Usage Resources UI.
The safe default for commit products is Percentage. A 25% Percentage adjustment against an anchor rate of $1.00 produces the same $0.75 effective rate as an Override with AdjustmentValue=0.75 — but only the Percentage variant renders consistently in the standard Manage Usage Resources window. Override values silently disappear from the UI in some commit contexts, which wastes debugging hours on a setup that is already correct at the data layer.
If your sales team thinks in dollars per unit rather than percentages, do the conversion before you write the record. Back-compute the percentage that matches the target USD rate and store it as Percentage. Keep Override for situations where you have tested it end-to-end and confirmed the UI renders correctly.
What Happens at Rating Time
When a customer consumes usage under a quote that has both the anchor and the commit active, the rating engine walks the drawdown graph in a specific order. The UsageCommitmentPolicy picklist controls the fallback behavior once the commit is exhausted.
- Lowest Commitment Rate: after the committed quantity is used up, overage continues at the commit’s discounted rate — the discount “sticks” beyond the commit. This is the more generous option for the customer.
- Bounded Object Rate: after the committed quantity is used up, overage falls back to the anchor’s full list rate. The commit essentially expires at the limit.
This choice belongs to deal strategy, not implementation. Sales negotiates which policy applies per commit, and finance wires it into the PURP on the commit product.
Gotchas That Waste Implementation Time
- Commit products need PURs for every Usage resource the anchor has, not just the commit resource. Teams that build a commit with only a Token PUR see blank rows in the Manage Usage Resources UI.
- Base rate cards are blocked for commit products. The validator throws “You can’t create a Rate Card Entry with the Rate Card of type Base when the selected Product has one of the commitment usage model types.” Use Tier only.
- Commit-to-anchor runtime binding is a manual admin step. Activating the order does not create the
UsageCommitmentAssetRelatedObjectthat links the commit asset to the anchor asset. Without that record, consumption routes to overage instead of the commit bank. Build a record-triggered flow or train admins to create it. - Refresh the tier-specific decision tables, not just the rate card ones.
Rate_Adjustment_by_Tier_Entries_2,Tier_based_Rate_Adjustment_by_Rate_Card_Entry_ID, andRate_Adjustment_by_Tier_Resolution_Decision_Tableare what make commit discounts render in the UI. Skipping them leaves rates blank. - PUG validity defaults to 1 Month refresh. Production reference implementations set every Grant and Commit PUG to
ValidityPeriodTerm=1 ValidityPeriodUnit=Monthso grants reset monthly. The only exception is the anchor’s token allowance, which runs for the full term with null validity.
Which Commit Flavor Should You Pick?
| Use Case | Best Fit |
| Customer wants one discount bucket across all resources | Token Commit (Commit) |
| Customer thinks in dollars, wants to commit a budget | Monetary Commit (CommitmentSpend) |
| Customer commits to specific resource volumes with different discount tiers per resource | Quantity Commit (CommitmentQuantity) |
| You want volume-tiered discounts (10% up to 1K, 20% up to 5K, 30% above) | Token Commit with TIER rate card pattern |
| You want the simplest “10% off everything” story | Token Commit with FLAT rate card pattern |
| Different resources need different discount rates | Token Commit with EACH rate card pattern |
Related Resources
- Complete Guide to Usage Management in Salesforce Revenue Cloud — the foundation article on anchor products, grants, rate cards, and the full quote-to-invoice pipeline
- Pricing Procedures in Salesforce Revenue Cloud — how the pricing engine resolves list price, discounts, and rate card lookups at quote time
- Setting Up Revenue Cloud from Scratch — prerequisites for any usage product implementation
Conclusion
Commit products are not a special case bolted onto usage management — they are a full parallel structure that mirrors the anchor and adds a commit-specific discount layer. Once you internalize that every commit needs PURs for every anchor resource, that the rate card type is always Tier, and that the quote line price is a negotiated number independent from the rate math, the three flavors stop feeling mysterious and start feeling like three straightforward commercial options.
The next article in this series walks through rate card mechanics in depth — Base versus Tier, Percentage versus Override, and every reason the Manage Usage Resources UI ever renders blank. If you are building a usage product roadmap for your organization, that is the next piece you want.