A better way to manage your CPQ product rules in Salesforce

The Configuration Guide

We’ve compiled the results of our research and created a guide to both product- and attribute-based configuration, showing you the reality of each option, and outlining why attribute-based configuration is the right choice to future-proof your tech stack.

CPQ product rules test line items for error conditions and unauthorized combinations.

All product rules perform an action triggered by error conditions. There are four product rule types.

• Validation Rules: confirm quotes only contain approved configurations. Invalid configurations trigger an error message and prevent saving until validated.
• Product Selection Rules: add, hide, require, or exclude certain options when specific conditions are met.
• Filter Rules: prefilter bundle options to display chosen options. Also, creating dynamic bundles limits maintenance by filtering options that may change over time by feature category.  
• Alert Rules: They're almost identical to validation rules with conditions that trigger an error message. However, they're more like recommendations and best practices than requirements. So, users can choose to continue anyway.
• Other functions also work alongside rules. When using a summary variable, Salesforce CPQ applies a math function to the chosen number field(s). Using lookup queries, Salesforce CPQ checks object field values for certain conditions. They can power price and product selection rules when applied to the correct product rule fields in Salesforce CPQ.

Example: Consider a shoe store having a buy two get one (of equal or lesser value) free sale, limited to 15 pairs per purchase, with free shipping over $100. Summary variables could find the item amount and total price. This could trigger selection rules to automatically add free shipping when eligible and validation rules to validate the item limit.

A composite operator (additional math function) could divide the item total by two and a lookup query could determine the correct number of free pairs earned. If they have an odd number of pairs, an alert message could inform them that adding one pair could earn them another free pair. Filter rules could then display the prefiltered list of eligible free pair options.

Salesforce CPQ configuration rules are what determine which bundles product rules apply to.

Salesforce CPQ product configuration requires the use of both configuration rules and product rules.

To simplify the difference, a product rule is what applies option constraints in Salesforce CPQ by checking line items for their assigned error conditions and responding with the matching actions. Configuration rules in Salesforce CPQ connect the product rules to the bundles they apply to.  

Salesforce CPQ product rule fields contain details about what constitutes an error condition for the product rule and how it should respond. They're not the same as price rules in Salesforce CPQ. A price rule in Salesforce CPQ also has corresponding conditions and actions. However, they affect the quoted cost as a means of price automation.

Salesforce CPQ product rules examples can illustrate the process. Electronics and accessories sellers might use a Salesforce CPQ product selection rule to only show phone case options when a phone is part of the bundle.

A filter rule could dynamically present only compatible cases. An alert rule message triggered by adding a regular charging cord might recommend a fast-charging cord when available. Finally, a validation rule can verify that the quote matches your predetermined conditions.

Good Salesforce CPQ price rules examples for this scenario include price rules that account for each added option's cost and ones that remove the shipping fee above a spend threshold. The rules help throughout the quote-to-cash process.

Now we'll be giving a brief overview of how to create product rules in Salesforce.

While there are some differences, the general procedure is similar. The filter product rule in Salesforce CPQ is the only one that doesn't require all these steps.

Basic Steps:

1. Create product rule.
2. Create error condition(s).
3. Create action(s).
4. Create configuration rule.

The biggest differences are the field detail inputs. Here's a quick rundown of each field.

Product Rules Fields:

• Type: Product rule type
• Conditions Met: Choose to apply the rule when any, all, or custom conditions are met
• Scope: What the rule applies to (i.e., product, quote, etc.)
• Evaluation Event: When the rule runs
• Message: The notification the user reads
• Active: Check to activate

Error Conditions Fields:

• Tested Object: Object containing tested field
• Tested Field: Specific quote object field-tested
• Tested Variable: Use lookup query to select the desired summary variable (created beforehand)
• Operator: Relationship between filter information and evaluated information (i.e., equal to, starts with, contains, etc.)

Either fill in the tested object and tested field OR the tested variable, NOT both!

Action Fields:

• Type: Action type (i.e., add, hide, disable, etc.)
• Product: Product the action applies to (i.e., add or remove what?)
• Required: Selects the option on the quote

Alternatively, filter product rules do something special in Salesforce CPQ, hide product options that are irrelevant, and display only the ones in the specific category you want users to choose from. It's special because it does this dynamically by presenting only options in a specific feature category. 

To apply a dynamic filter in Salesforce CPQ, create matching custom fields—like a checkbox or picklist—in the product records and product option object. Then create a product filter rule and action. Then create the configuration rule and connect the product filter rule to the feature. Make sure your feature selection method is set to dynamic, and voila! That's how you create a dynamic bundle in Salesforce CPQ.

Any of these capabilities on their own would be a huge leap forward for a lot of businesses.

This kind of automation saves businesses a ton of money by eliminating time-consuming, repetitive, administrative tasks and data entry. That's especially true for the dynamic bundles.

However, for businesses with multiple product or configuration rules as well as those with more sophisticated logic demands, such as manufacturing businesses, it's not such a huge win. While these features would likely be a big help to them as well, Salesforce CPQ can't handle that kind of complexity.

Even their own documentation says:

"The number of active quote product rules affects performance of the Edit Lines screen and should be limited to avoid Salesforce governor limits."

Businesses that would ordinarily be left out because of this can get the same great products and services they love from Salesforce using Logik.io for advanced product rules. Logik's state-of-the-art software lets you keep your data in Salesforce and enjoy all they have to offer without the loss of performance businesses with complex logic all too often suffer.

Access our next-generation headless configuration engine with lightning-fast speeds and streamlined performance, perfect for reps to lead customers through the omnichannel sales process with ease. Our guided selling functionality is ideal for reps, B2B customers, or eCommerce customers to successfully navigate the process.

Our feature-based, solution-oriented configuration engine eliminates the need for customers to wonder which specific parts, grade of steel, or gen of software is right, creating an experience they'll love. They can keep their focus on the features and solutions they need rather than the SKU that can provide them, where it belongs.

With our headless commerce approach for extra speed, our proprietary solving engine purpose-built to optimally order configuration rules, automatic BOM generation, matrix loader, and advanced function builder, you have all the power you'll ever need. Plus, our partnership with Threekit brings you advanced visual configuration as well! Logik for Salesforce will change the way you do business.    

There's a lot of functionality in product selection rules Salesforce CPQ customers seem to like.

When using Salesforce CPQ, hide products and reveal options based on specific conditions. Many SaaS companies appreciate the features for usage-based products Salesforce CPQ provides. They allow products to be billed differently depending on how much they're used.

A good example of this is phone service and internet providers. They bill many customers based on how much data they use each month. They also have certain features that are only available in a bundle with others. The most common example of this is requiring that certain internet bundles come with a landline. That is the kind of bundle you could use product selection rules for.

If a user tries to get one of the features you want to be sold exclusively as a bundle by itself, Salesforce CPQ product rule validation could ensure that attempt is caught, and an error message is presented to inform the user that one cannot be bought without the other. These are just some of the useful scenarios made possible with these product rule combinations.

Another helpful feature, particularly for guided selling, is the ability to assign products individual Salesforce CPQ product rule configuration attributes.

Product attributes—Salesforce's term for the specific features that can vary for a given product—help you define the different facets of the items you sell. Reps or customers can describe the specific elements they're looking for and search for products matching those details.   

Let's use our electronics store example again. If you sell various smartphones, your products might include the Samsung Galaxy S22. Salesforce CPQ product features that differ between product variations would be things like the model, storage space, color, screen size, etc.

The great thing about attributes is that you don't have to create a separate one for each variation factor on every individual product. Instead, you create a list of product attributes to choose from and then group them into sets that apply to one or multiple products.

For example, the Samsung Galaxy S22 could contain an attribute set for screen size. The attributes in the set would be 6.1 inches, 6.6 inches, and 6.8 inches. That would be an example of a configuration attribute. Global attributes in Salesforce CPQ allow you to create attributes that can apply to any product. Since global attributes aren't product-specific, the only Salesforce CPQ product fields you have to fill in are the name and target fields.

ADDITIONAL RESOURCES