#Revenue Cloud84 debatiendo

  I'm implementing Term Discounts in Salesforce Revenue Cloud Advanced (RLM) :      I have completed the implementation, but the custom pricing is not getting applied to the Quote.  Configuration completed

•  Created a custom object to store Term Discount records. 
•  Created the required Formula Based Pricing. 
•  Created a Decision Table with term ranges and discount percentages. 
•  Created a Price Adjustment Matrix. 
•  Added the Formula, Decision Table, and Price Adjustment Matrix to the Pricing Procedure. 
•  Added the Pricing Procedure to the active Pricing Recipe. 
•  Configured the required constants. 
•  Configured the Context Definition mappings. 
•  Activated all the required metadata (Pricing Procedure, Pricing Recipe, Decision Table, Price Adjustment Matrix, etc.). 

Expected Result

The discount should be applied based on the subscription term.

Example:

•  12–24 months → 10% 
•  25–36 months → 15% 
•  37+ months → 25% 

Actual Result

The Quote pricing is calculated, but the custom Term Discount is never applied. The Net Unit Price remains unchanged.

I have verified the configuration multiple times against the article but cannot identify what is missing.

Questions

1.  Is there any additional configuration required in Revenue Cloud Advanced that is not covered in the article? 
2.  Besides the Pricing Procedure, Pricing Recipe, Decision Table, and Price Adjustment Matrix, are there any prerequisites required for custom pricing logic to execute? 
3.  Has anyone successfully implemented this functionality in a Revenue Cloud Advanced Developer Edition? If so, were there any additional setup steps required? 
4.  What would you recommend checking when a custom pricing implementation is configured correctly but the pricing is still not being applied? 

Any suggestions or guidance would be greatly appreciated.

Thank you! 

In Salesforce Revenue Cloud (not CPQ), the standard QuoteLineGroupId lookup field on Quote Line Item won't persist when set via the Transaction Line Editor, even though the Context Definition has an attribute (SalesTransactionItemGroup) mapped to it under the SalesTransactionItem node's Object Mapping; I've confirmed the attribute is Input/Output enabled and mapped correctly, ruled out any downstream trigger/flow overwriting the value (direct API updates to QuoteLineGroupId hold fine), and ruled out a data-type mismatch since other Text-attribute-to-Lookup-field mappings on the same node (Vendor__c, OEM__c, Contract_Vehicle__c) work without issue — the key difference with QuoteLineGroupId is that its target object, SalesTransactionGroup (mapped to QuoteLineGroup), is itself a node within the same Context Definition tree rather than an arbitrary external lookup, and I suspect there's a Node Relationship configuration between SalesTransactionItem and SalesTransactionGroup that's competing with or overriding the manual Object Mapping for that field; has anyone run into this specific case of a standard grouping field not sticking when its target is also a context node, and if so, where in the Node Relationship setup should I be looking to resolve it?  

UPDATE: This is the response from SFDC Support as of 8/1/2026:  

 The behavior you are experiencing is a known limitation and is currently considered expected behavior in the Transaction Line Editor (TLE) within Revenue Cloud Transaction Management. 

Root Cause 

The QuoteLineGroup object is not configured as a valid custom foreign key target. Specifically, the entity definition for QuoteLineGroup does not include the canBeCustomForeignKeyTarget="true" configuration, which is available on most other standard entities. As a result, the TLE is unable to properly persist updates to the QuoteLineGroupId lookup field in the same way it does for other lookup fields. 

This behavior is also consistent with the broader known limitation that standard Salesforce lookup filters and certain lookup field behaviors are not fully supported within the TLE, unlike on a standard Lightning record page. 

This has been assessed internally as a feature request for the QuoteLineGroup object—specifically, to enable canBeCustomForeignKeyTarget, allowing the object to function as a standard foreign key lookup target within the TLE.

#Revenue Cloud  #TLE  #Quote Line Items  #Quote Line Item  #Quote Line Group  #Quote Line Groups

Hi everyone, 

I'm currently working on a Salesforce Revenue Cloud implementation and would appreciate some guidance on a pricing scenario. 

Business Scenario

We sell telecommunications service bundles.

For example:

Parent Product

• Internet Service Bundle

Component(Child product)

• Router

During product configuration, the user selects different attributes.

Bundle attributes (Parent)

• Bandwidth (20 Mbps, 50 Mbps, 100 Mbps, etc.)
• Contract Term (12, 24, and 36 months)

Component attribute (Child)

• Router Model (FortiGate 40F, FortiGate 60F, etc.)

These attributes impact the service price.

Requirement

The customer wants to manage pricing without having to update Product records every time a price changes.

As an initial approach, I created a custom Price Table object that stores information such as:

• Product
• Selling Model
• Bandwidth
• Contract Term
• Router Model
• Monthly Recurring Charge (MRC)
• Non-Recurring Charge (NRC)
• Effective Start Date
• Effective End Date

My idea was to use this table together with Lookup Tables and a Pricing Procedure to retrieve the correct MRC and NRC based on the selected combination of attributes.

Where I'm blocked

The part I'm struggling with is building the Pricing Procedure when the price depends on attributes coming from different levels of the product configuration.

For example:

• The Bandwidth attribute belongs to the parent bundle.
• The Contract Term attribute also belongs to the parent bundle.
• The Router Model attribute belongs to a child component within the bundle.

I need to use the combination of these attributes to retrieve a single price from my Price Table.

My questions are:

• What is the recommended way to access both bundle attributes and child component attributes within a Pricing Procedure?
• Is it possible to expose those attribute values through the Pricing Context or SalesTransactionItem so they can be used in a Lookup Table?
• How have you implemented similar scenarios where pricing depends on attributes distributed across both the bundle and its child components?

If anyone has implemented a similar solution using Context Definitions, Pricing Procedures, or Lookup Tables, I would really appreciate any guidance, examples, or best practices you can share. 

Thank you in advance!