%20(3)%20(1).png)
.png)
Ask three people why a customer got 15% off and you may get three answers. The discount came from a price rule, an Apex class, or a manual override, and the reasoning behind it is rarely recorded anywhere.
Salesforce Spring '26 release changes that. Promotions turn a discount into a record with dates, eligibility, priority, and a visible effect on price – one object anyone can point at.
This article covers how to set them up step by step, two worked examples, and the mistakes that stop a promotion from reaching the quote.
Before, promotional pricing in Revenue Cloud was an assembly job. Teams reached for manual discounts, Salesforce CPQ price rules, discount schedules, decision tables, or an external pricing engine – often several at once. Each worked in isolation. Together they made a promotion hard to govern:
⮕ a rep couldn't always say why a discount had landed
⮕ an admin maintained the logic in three places
⮕ and marketing had no single view of what was live, when, and for whom.
The native Global Promotions Management engine collapses that into one workspace. Pricing and marketing teams define a promotion, set its eligibility and dates, and watch its effect land as a discrete line in the price waterfall. The benefit is now a record, not a typed-in number – which is exactly what auditing has always needed.
The order below matters. Skip a layer and the promotion may exist as a record yet never evaluate, or evaluate and never show.
Available in: Enterprise, Unlimited, and Developer Editions of Revenue Management with the Revenue Cloud Advanced license, and the Global Promotions Management Basic Add-On license or Loyalty Management – Growth or Advanced license.
Promotions depend on Context Service to feed transaction, customer, product, and line-item data into evaluation. Most ARM orgs already have it on – confirm your extended Sales Transaction context definition is active and mapped.
Then, in Setup → Global Promotions Management Settings, turn on Global Promotions Management, Product Catalog Management (if promotions will touch bundles), and Promotion Evaluation and Execution.
If users need to see promotion details in the transaction UI, also enable Price Waterfall and Price Waterfall Persistence. The waterfall is what turns the promotion from a hidden adjustment into a pricing step anyone can audit.
Note! Global Promotions Management cannot be switched off once enabled – the same rule that governs the irreversible ARM settings applies here. Sandbox it first.
Why it matters: Promotions run on the Revenue Cloud pricing and context framework. Without this groundwork the promotion can exist as a record and still fail – either it never evaluates, or it evaluates and never surfaces in the transaction experience.
A rule library maps context-definition tags to the fields Promotions use for eligibility. From the App Launcher, open Rule Libraries → New, name it, and for Context Definition Name enter the API name of your extended sales transaction context definition – the same one your transaction pricing procedure uses. Set Usage Type to Promotions with Revenue Management and save.
Open the rule library from the Rule Library Versions list, then add each required mapping: in the Custom Tag Mapping section click New, pick a mapping name, and select its context tag.
Once every required mapping is in place, activate the rule library version.
This is the step with a trap in it. Open your active pricing procedure and deactivate it, then delete the derived pricing element – promotions and derived pricing cannot coexist in the same procedure.
After the Apply bundle-based adjustments container holding the Bundle-Based Price element, click Add component and select List Group. Then modify the List Operation element:
IsContracted, Operator Is Null.IsContracted, Operator Equals, Value false.ItemPricingSource, Operator Not Equals, Value LastTransaction.(1 OR 2) AND 3.%20(1).png)
In List Group, after List Operation, add a Promotion Execution element and select your rule library. Set Promotion Scope to Line, then map the variables:
ItemNetTotalPrice; Quantity: LineItemQuantity; Input Unit Price: NetUnitPrice.NetUnitPrice; Subtotal: ItemNetTotalPrice.
Save and activate the new version of the pricing procedure.
Placement is not cosmetic. Land Promotion Execution too early and it fires before a required adjustment; too late and it hits a price that's already locked.
Why it matters: Because Promotions are not just marketing records. They have to execute inside the pricing procedure to affect transaction pricing at all.
Flows control whether users can see and apply eligible promotions. In Setup → Flows, open the product configurator flow (the default is Default Product Configurator Flow).
Modify each element that contains the Product Configurator Product Header component:
S01_ProductConfiguratorUI.S01_Header in the default flow.{!S01_DataManager.eligiblePromotions}.
%20(1).png)
Set the same value on the S01_Summary component, then save the flow.
Why it matters: Every element carrying the product header component has to be updated, and the summary component alongside it. Update one and miss the other, and eligible promotions appear at one point in the configurator and disappear at the next.
In Setup → Revenue Settings, enable Promotions for Transactions and select your rule library.
If you’re using channel-based promotions, select the promotion context mapping for product discovery.
a. In Setup, find and select Product Discovery Settings.
b. Select your promotion context mapping.
Finally, grant read access to the Promotion, Promotion Execution Evaluation Group, Promotion Execution Evaluation Group Item, and Coupon objects – plus the runtime and designer permission sets.
Why it matters: Miss the permissions and reps simply won't see promotions at all. Required permission sets vary by role and can include both runtime and promotion designer or viewer permissions.
From the App Launcher, open Promotions and Offers and click New Promotion. Set name, display name, priority, optional promotion code, and start/end dates, then select the rule library.
Priority Number controls display order: when several rules inside one promotion are eligible for a cart, it decides the order they're shown to the customer.
Optionally update eligibility criteria and coupon codes for cart-based transactions, then click Next. Select the template for the promotion configuration and continue. Configure the promotion template against the product and its selling models.
%20(1).png)
Two things to know before you activate:
Save and activate.
Why it matters: Bundle promotions only work when the template points at products inside the bundle. Pick a child product or category from outside it, and the promotion activates normally and never applies to anything.
When more than one promotion qualifies, the evaluation method of the subgroup decides the outcome – set it in Promotions & Offers → Configure Evaluation and Execution:
This choice is easy to set and easy to get wrong. Stacked on a margin-sensitive catalog gives away more than intended; First Eligible on a catalog that expects best-price behaviour underdelivers. Decide it against your commercial policy, not the default.
Alongside evaluation methods, the console gives program managers a calendar view: select a date range and see which promotions are active or inactive across it. Grouping and filters make it easy to spot duplicates and find the white space where a new promotion fits. On a catalog with more than a handful of live offers, this is where scheduling conflicts surface before a customer does.
A distributor runs a 15% Q4 discount on an entire accessories category, but only through the partner channel; direct sales must never see it. You target the promotion at the category, add the channel tag to the rule library, and restrict eligibility to the partner channel.
Result: a partner quote surfaces the discount in the waterfall as its own step; the same product on a direct quote shows list price with no trace of the promotion. One record, two behaviours, no Apex.
A hardware vendor offers $225 off a configured laptop productivity bundle – but only when the bundle actually ships as a bundle. The promotion targets the root product and applies cleanly: $1,499.99 becomes $1,274.99, logged as a structured record rather than a hand-typed figure.
Result: the discount applies to the bundle as a whole through its root product, not to individual lines inside it.
Promotions are easy to read as a marketing feature, and that is where most implementations go wrong. Setting them up is not a checklist of individual switches – it is one chain running through Context Service, Global Promotions Management, a rule library, a pricing procedure, configurator flows, and permissions.
Teams that enable those pieces one at a time, without looking at how they interact end to end, hit the same failure: nothing errors, and the discount simply never reaches the quote. The dependencies below are where that chain usually breaks:
Promotions are a real upgrade: discounting that used to live in code now lives in a governed, auditable workspace, visible in the waterfall where anyone can trace it. That closes a gap teams have worked around for years.
The catch is that the upgrade isn't a single switch. A promotion only reaches the quote if six things line up behind it – context, settings, a rule library, a pricing procedure, flows, and permissions. Set Promotions up well and they handle the discount. Miss one link in the chain and they handle nothing at all.
Promotions reward setup that was done in order. Build the chain deliberately and the discount lands where it should; assemble it piecemeal and you'll spend the time you saved looking for the step that was missed.
When did Promotions become available in Agentforce Revenue Management?
Promotions are available in Agentforce Revenue Management as of Spring '26, through the native Global Promotions Management engine.
Can I use Promotions and derived pricing in the same pricing procedure?
No. The two can't coexist – you delete the derived pricing element before adding Promotion Execution. Design the procedure around one approach.
What's the difference between Stacked, First Eligible, and Highest Discount?
Stacked calculates every eligible promotion and adds them together; First Eligible applies the top-priority one per line and cart; Highest Discount applies the single largest per line and cart. The method belongs to the subgroup and decides how discounts combine.
Why isn't my promotion applying to a bundle?
The usual causes are a child product or category outside the bundle (which blocks it), missing record access or permission sets, or a Promotion Execution element placed wrong in the pricing procedure.
Why isn't the discount showing in the price waterfall?
Price Waterfall and Price Waterfall Persistence have to be enabled in Global Promotions Management Settings. Without them the promotion can apply correctly and still stay invisible to the rep.
Do Promotions apply automatically at renewal?
Not by default, and usually they shouldn't. The recommended pricing-procedure filter keeps promotions off contracted and last-transaction lines. Confirm renewal behaviour against your own model rather than assuming.
.png)
.png)
.png)