Decide When Rules Evaluate

Learning Objectives

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

• Describe where and when product rules evaluate their conditions.
• Identify which rules can run at each evaluation event.
• Set configuration attributes and product options to trigger rule evaluation.
• Determine the order in which selection-type rules run relative to each other.

A Time and Place for Every Test

In the last unit you learned about error conditions, which are tests to check if a rule should run. But when should CPQ perform the tests? The answer to that can make a big difference in the user experience. For example, imagine you create a rule that pops up an error message if there’s an issue with the way a bundle is configured. Now imagine you’re the sales rep trying to fix the issue, and the error keeps popping up after every little change you make. That would get annoying pretty fast. That bad experience happens when CPQ evaluates the rule’s conditions too often. It would be better if the rule only tested conditions when sales reps click Save.

Thankfully, you can control exactly when CPQ evaluates error conditions, and in this unit you learn how.

Product Configuration vs Quote Line Editor

Sales reps who use CPQ to create quotes spend a lot of time on three pages.

• Product Selection: where they choose which products to add to the quote
• Product Configuration: where they configure bundles
• Quote Line Editor: where they see pricing and apply discounts (among other things)

A product rule can run on either the Product Configuration page or on the Quote Line Editor, but not both! It’s rare that the same business logic needs to be in both places, but if you find yourself in that situation, you have to create two separate rules.

The Scope field on the product rule record tells CPQ where the rule should run.

As you might guess, a scope of “Product” means the rule will run during product configuration, and a scope of “Quote” will make it run on the Quote Line Editor.

Evaluation Event

If the Scope field tells CPQ where the rule should run, then the Evaluation Event field helps tell it when it should run. There are five times that CPQ can evaluate rules as a sales rep moves through the quoting process. The combination of your Scope and Evaluation Event field choices determine the timing.

The tricky part is that CPQ avoids running some rule types at certain times. For example, CPQ does not evaluate Alert rules when the user first loads the Product Configuration page. So, choosing a Scope/Evaluation Event combination of Product/Load means CPQ will never evaluate your Alert rule, and therefore never run it! The last column in the table above shows which rule types are evaluated for every point in time.

Finally, you can set the Evaluation Event to “Always,” but be careful, this value is a little misleading. “Always” doesn’t mean a rule is always evaluated. Instead, it’s better to think of the “Always” value as meaning “All Applicable.” Take a look at the first row in the chart again. You can see that CPQ will NOT evaluate Validation rules when the Product Configuration page first loads. So, if you choose “Always” for the evaluation event of a Product-scoped Validation rule, it will only be evaluated when a user makes edits or clicks Save on the Product Configuration page.

The “Always” event is a safe choice if you’re not sure which other event to choose. But if you find that your rule is a bit too overactive, consider choosing a specific event.

Don’t Wait, Apply Immediately!

Product rules that use “Edit” for evaluation event are meant to provide real-time feedback to sales reps. Reps make a change, a rule runs, and they see something happen. This is a great feature, when used in moderation. Too many rules running too often makes for a bad user experience.

Thankfully, rules with the Edit event don’t actually evaluate every time an edit occurs, only when certain edits occur. And you get to decide which edits call for evaluation. For example, you might have a bundle with 20 options, but only one is tied to a rule. In that case, you'd only want the rule to run if that one specific option is selected or unselected (or in other words, edited). To tell CPQ to evaluate "Edit" rules when a specific option is selected or unselected, check the "Apply Immediately" checkbox on the option record.

There's one other place you can find an "Apply Immediately" checkbox, and that's on a Configuration Attribute record. In the Personalize Smartwatches with Salesforce CPQ Attributes badge you learn that attributes, such as Size and Accent in the below screenshot, allow sales reps to define properties of a bundle to make it specific to their customer's needs.

Attributes are often used in product rules as part of the condition logic. If you want CPQ to evaluate a rule the moment a sales rep changes the attribute value, make sure the rule's evaluation event is "Edit" then check "Apply Immediately" on the configuration attribute record.

Finally, there’s one last way to tell CPQ to evaluate all edit-event product rules: the Apply Rules button. This allows your sales reps to make many changes that CPQ might need to evaluate, then CPQ evaluates all edit-event rules at once.

Some customers use the Apply Rules button as an alternative to apply immediately as a way to reduce how often validation rules trigger. Relying only on Apply Rules could be dangerous if you have Validation rules set to the Edit event, since there’s a chance they never run. If you use Validation rules without Apply Immediately, at least set the evaluation event to Always. That way, clicking Save will evaluate your important Validation rules as a final safeguard.

Also be careful when using Apply Rules as an alternative to apply immediately for selection rules, since selection rules are never evaluated when Save is clicked. You can easily end up with selection rules that don’t run. Only consider this setup if your selection rules are used for guidance, and not if they’re used to ensure technically valid configurations.

Evaluation Order

There’s one last thing that can affect when CPQ evaluates your rules: Evaluation Order. This optional field allows admins to sequence selection type rules that check or uncheck options in a bundle. For example, you can have a general-purpose rule that preselects common options for all customer industry types. Then, you can have a second specialized rule that unselects a few options for just one industry.

In that scenario, you want the general rule to run first, otherwise it rechecks options you actually want unchecked.

To avoid that issue, just set the Evaluation Order of the general rule to 10, and the specialized rule to 20.

Rules are evaluated in numeric order, so 10 first, then 20, and so on. We recommend that you use increments of 10 when ordering your rules. That way, if you need to insert a rule between 10 and 20, you can just number it 15 and not have to renumber everything after 1.

Evaluation Order, along with Scope and Evaluation Event, give admins a huge amount of control over when and where CPQ evaluates rules. In the next unit we look more closely at rules related to bundles.

Resources

• Salesforce Help: Product Rule Guidelines
• Salesforce Help: Product Option Fields
• Release Notes: Apply Edit Rules Efficiently in the Configurator