We recently introduced a pricing calculator that factors in things like room count, hotel type, etc. The calculator may determine a solution should be priced at $6,000 instead of our standard Salesforce list price of $6,540.
The challenge is around how to represent this in Salesforce.
Currently:
- Sales Price = final price after discount
- ARR and Total Price calculations rely on Sales Price
What leadership would like:
- Allow reps to edit the Sales Price directly
- Still apply/display a discount separately
The issue is that if reps edit the Sales Price and also apply a discount, we would likely need another field to represent the “true final price after discount.” Then downstream calculations (ARR, Total Price, reporting, etc.) become inaccurate unless we redesign a lot of the logic.
For example:
- Standard price = $6,540
- Calculator says final customer price should be = $4,600
- If Sales Price is manually changed to $5,000 and a $400 discount is applied, ARR still reflects incorrectly because Total Price is pulling from Sales Price.
Alternative approach: Ignore the calculator’s intermediate discount logic and simply use Salesforce discounts to get to the correct final number. But that can result in very large discounts (ex: needing a $1,950 discount instead of the calculator’s displayed $400 discount), which leadership doesn’t love from a visibility/reporting standpoint.
Has anyone solved something similar with dynamic/calculated pricing while still keeping ARR/reporting accurate?
On the Opportunity Product (OpportunityLineItem) object:
1. Add custom fields: Calculator_Price__c, Rep_Discount_Amount__c, Final_Price__c (formula)
2. Use a Screen Flow or LWC component to run the calculator logic and write to Calculator_Price__c
3. Lock Sales Price from direct edit — use Final_Price__c as the true price field
Update ARR/Total Price rollup formulas to reference Final_Price__c
