Learn When to Use the Special Price Field

Learning Objectives

After completing this unit, you’ll be able to:

• Identify which price fields and non-pricing fields are safe to target with price rules.
• Create price rules that do not perform recursive calculations.
• Construct a rule that targets the special price field.

Two Prices to Target

As we mentioned in unit 1, Salesforce CPQ has many out-of-the-box tools for adjusting pricing, so many that we’ve devoted three badges to them.

• Pricing Methods for Salesforce CPQ
• Discounting Tools in Salesforce CPQ
• Subscription Pricing in Salesforce CPQ

To keep track of how CPQ arrives at a final price for the customer (also known as Net Price), it uses a bunch of intermediary fields to represent specific adjustments. For example, Regular Price represents adjustments based on Discount Schedules, and is prorated if the quote line is a subscription. As a reminder, here are those fields.

• Original Price
• List Price
• Special Price
• Regular Price
• Customer Price
• Partner Price
• Net Price

So far you’ve only made price rules that target List Price. It may surprise you to learn this, but we recommend that you target only one other price field: Special Price. You should leave Original Price alone so that it can act as a reference point, to compare against other prices to trigger approvals and validations, or to simply calculate margins correctly.

As for Regular Price, Customer Price, Partner Price, and Net Price, those are all prorated prices. Accounting for the prorate multiplier is problematic. The calculations quickly become complicated, and it’s very easy to introduce rounding errors. So, although it’s technically possible to target those fields, you really shouldn’t. Instead, stick to List Price and Special Price.

Avoid Recursive Calculations

List Price is often the best price field to target when using price rules, but there are exceptions. The most common exception is when a price rule needs to use List Price in the source of its price action. It’s a really bad idea to use the same price field in both the source and the target of a rule. Doing so is likely to cause a recursive calculation. For example, imagine that you have a price rule that targets List Price, but also has a Source Formula that contains List Price: SBQQ__ListPrice__c * 0.9.

If the List Price starts at $100, clicking calculate once processes $100 * 0.9, making List Price $90.

Looks good so far, but...

Clicking calculate again processes $90 * 0.9, making List Price $81.

Uh-oh...

Clicking three times processes $81 * 0.9, making List Price $72.90.

This is bad. The value of List Price depends on how many times you click calculate, and that should never happen!

So to recap, either target List Price, or use List Price as a source, but not both. This goes for any field you plan to use in a price rule.

The Most Special of Prices

There’s at least one scenario when you have to use List Price as a source in a pricing adjustment. As you learn in the Pricing Methods in Salesforce CPQ badge, List Price sometimes represents the price of a bundled option. In other words, when a product is sold in a bundle, it gets a different price than when it’s sold on its own. This encourages bundle sales.

But what if you need to adjust the bundled price? That’s where Special Price comes in to help. Special Price is the next price in the CPQ price waterfall, meaning its value is calculated based on List Price. Special Price is not prorated, so you can safely update its price without worry of factoring in subscription term lengths.

Let’s consider a use case in which AW Computing wants to adjust pricing for products while keeping bundled prices intact. Currently it sells a few laptops that have SSD hard drives as bundle options, and those options use option pricing. Now AW Computing would like to offer small businesses a 20% price reduction for all SSD drives, which should apply to the already reduced bundle pricing. A price rule that targets Special Price can do this easily. Start by creating a new price rule record.

1. In the navigation bar, click Price Rules.
2. Click New.
3. For Price Rule Name, enter Small Business SSD Special Price.
4. For Evaluation Scope, choose Calculator.
5. Check Active.
6. Click Save.

OK, now for the first price condition, which checks if the account is a small business. You do this by checking if the number of employees on the account is less than 50.

1. In the Price Conditions related list, click New.
2. For Object, choose Quote.
3. For Tested Formula, enter SBQQ__Account__r.NumberOfEmployees.
4. For Operator, choose less than.
5. For Filter Type, choose Value.
6. For Filter Value, enter 50.
7. Click Save.

And now for the condition that checks if the product is an SSD hard drive. Luckily AW Computing uses a consistent naming convention, so it’s easy to pick them out.

1. In the Price Conditions related list, click New.
2. For Object, choose Quote Line.
3. For Field, choose Product Code.
4. For Operator, choose starts with.
5. For Filter Type, choose Value.
6. For Filter Value, enter SSD.
7. Click Save.

Great, your rule will only fire when you need it to. Now to make sure Special Price gets the right value.

1. In the Price Actions related list, click New.
2. For Target Object, choose Quote Line.
3. For Target Field, choose SBQQ__SpecialPrice__c.
   This picklist value was added by Team Trailhead to make this exercise easier. In real life you have to add fields you want to target into the picklist yourself.
4. For Formula, enter SBQQ__ListPrice__c * 0.8.
5. Click Save.

Almost done, but there’s one last surprise action you need to take. Special Price has a unique quirk that you must address. Anytime you use a price rule to update Special Price, you must also update its companion field, Special Price Type, to have a value of “Custom.” If you don’t change Special Price Type to Custom, the price rule won’t work. So, for this use case you need one more price action.

1. In the Price Actions related list, click New.
2. For Target Object, choose Quote Line.
3. For Target Field, choose SBQQ__SpecialPriceType__c.
   Again, this is a field Team Trailhead added to the picklist to simplify the exercise.
4. For Value, enter Custom.
5. Click Save.

And there you have it, the Special Price is going to update as expected. Let’s try it out on a quote for a small business.

1. In the navigation bar, click Quotes, then choose the All list view.
2. Click Q-00050.
3. Click Edit Lines.
4. Click Add Products.
5. Check LAPTOP15.
6. Click Select.
7. Click the SSD512 option.
8. Click Save.
9. Click the quote line drawer arrow ( ) for the SSD512 quote line.
   This reveals everything that’s happening to the price. The Original Price shows the SSD’s price book price of $150. The List Price is the result of the bundle option pricing, $100. Then, your price rule kicks in to set Special Price to $80. Well done!
10. Click Cancel.

This exercise illustrates another great thing about price rules: you can use them to update non-pricing fields, such as Special Price Type. That’s great because there are all sorts of field types on the quote line, quote, and quote line group objects that you might want to control. For example:

• Quantity (numeric)
• Partner Discount (percent)
• Non-discountable (checkbox)
• Discount Schedule (lookup)

That said, you should never target formula fields. Let Salesforce handle their values; otherwise you’ll encounter all sorts of issues.

Finally, this exercise shows you that you can have a single price rule with multiple price actions to make many changes in one pass. For this exercise, you could add a third price action that sets Non-discountable to true. That would lock out manual discounts since SSD prices are already twice reduced.

The ability to act on many types of fields all in a single rule makes price rules extremely powerful. In the next unit you learn how to use another CPQ tool, Summary Variables, to make price rules even more capable.

Resources

• Salesforce Help: Salesforce CPQ Price Waterfall