Get Started with Product Rules
After completing this unit, you’ll be able to:
- Describe how the four types of product rules lead to accurate quotes.
- Identify the objects related to product rules, and how they contribute to business logic.
- Sign up for a special CPQ-enabled Developer Edition org.
Bring Order to Quotes with Product Rules
Like most of us, you’ve probably had the experience of buying something new and shiny, like a fancy camera, only to realize that you can’t use it without some other part you didn’t know you needed. Without a memory card, excitement about a new camera quickly turns into disappointment.
Unfortunately, this sort of thing also can happen when businesses buy from other businesses. Sales reps are only human, and they sometimes forget to include necessary products when they’re putting together a quote. Worse yet, they might include products that are incompatible. Erroneous quotes turn into erroneous orders. Not only is this frustrating to the customer, it costs everyone involved time and energy to make right.
Salesforce CPQ and its product rules are designed to help sales reps get the right products on the quote the first time around. Think of product rules as guardrails, there to help sales reps stay on course when navigating complex combinations of products and services. As an admin, putting a small amount of effort into creating product rules can save huge amounts of time and money for your business, while keeping your customers happy.
Product rules are often related to bundles, and throughout this module we talk a lot about the things that make up a bundle, such as options and features. For that reason, we highly recommend that you earn the Configurable Bundles in Salesforce CPQ badge first.
Product Rules for All Occasions
Product rules come in four flavors. Let’s look at the different types and the different ways you can use them to help your sales reps.
||Shows a message to your sales reps about a potential issue, but allows them to ignore it.
||Reminds sales reps of an upsell opportunity when they add a specific product to the quote.
||Shows a message to your sales reps about a problem they must fix before they’re allowed to save the configuration or quote.
||Tells sales reps they’ve selected the wrong toner for the printer they’re trying to add, and stops them from saving the illegal configuration.
||Automatically adds, removes, or hides products during bundle configuration. Also, automatically adds products to a quote.
||Pre-checks options in a bundle based on the account’s industry type; unchecks and hides options known to be incompatible.
||Shows only specific products in a feature that uses the Dynamic selection option.
||Lists only products with a product code that contains the letters “cable” in a mini product selection page.
When CPQ admins talk about product rules, they usually abbreviate the name of the rule. For example, they frequently shorten “validation product rule” to just “validation rule.” It’s OK to call it that. Just remember that it’s really a product rule of a certain type, and you go to the same tab in Salesforce to create all types of product rules.
Product Rules Are a Team Effort
CPQ administration usually requires you to create or update records of some sort, often across multiple objects. Product rules are no different. Each object related to product rules has a specific role to play in the show we call “Quote the Right Thing.” Let’s meet the cast of characters, starting with our star performer.
The phrase product rule has two meanings. First, it’s meant to describe the concept of business logic that helps sales reps get the right products onto the quote. Second, it refers to the actual object named product rule.
A product rule record has a few details about how the rule should behave, but mainly it acts as a container, or point of contact for any records on other objects related to the rule. There are four other objects that look up to it. A product rule can technically work without related records, but it won’t do much. To really make the best of product rules, you must include at least one of the other (following) related objects.
Simply put, error conditions control when rules trigger. With the right error conditions, your rules will only run when they need to.
Actions are records that hold the instructions for how CPQ should make changes to the way a bundle is configured. They’re mostly used for selection rules, but have a small role in filter rules too.
Sometimes businesses have many product rules that differ by only a little bit. In that scenario you can create one rule that looks to a data set to drive behavior. Lookup queries tie a product rule to the object that houses the data set.
You create a configuration rule to tell CPQ that a product rule applies to a specific configurable bundle. If you need the rule to apply to more than one bundle, you just create more configuration rule records.
In addition to the four main objects related to product rules, there are a few other objects that often contribute to how product rules behave.
Configuration attributes take the form of a field that sales reps can set during product configuration.
Although configuration attributes are not directly related to product rules, they’re often used as part of error conditions, and sometimes as part of lookup queries.
A summary variable is another CPQ-specific tool sometimes seen in product rules, and it does one simple task: add up values across many CPQ-related records. It’s a little like a rollup summary field, but with some advantages specific to CPQ. Summary variables are often used in error conditions, and sometimes actions.
So those are the objects that can possibly contribute to a product rule. Some rules use only a few objects, and others use all of them. By the time you’re done with this module, you’ll have created rules that use all parts.
Sign Up for a Developer Edition Org with Salesforce CPQ
To complete this module, you need a special Developer Edition org that contains Salesforce CPQ and our sample data. Get the free Developer Edition and connect it to Trailhead now so you can complete the challenges in this module. Note that this Developer Edition is designed to work with the challenges in this badge, and may not work for other badges. Always check that you’re using the Trailhead Playground or special Developer Edition org that we recommend.
Even if you've recently signed up for a special CPQ-enabled Developer Edition org, sign up for a new one now. We’re always adding new data. Also note that the Salesforce CPQ managed package expires after 90 days, so you may need a new org anyway.
- Sign up for a free Developer Edition org with Salesforce CPQ.
- Fill out the form. For Email, enter an active email address. For Username, enter a username that looks like an email address and is unique—but it doesn't need to be a valid email account (for example, firstname.lastname@example.org).
- After you fill out the form, click Sign me up. A confirmation message appears.
- When you receive the activation email (this might take a few minutes), open it and click Verify Account.
- Complete your registration by setting your password and challenge question. Tip: Write down your username, password, and login URL for easy access later.
- You are logged in to your Developer Edition.
Now connect your new Developer Edition org to Trailhead.
- Make sure you’re logged in to your Trailhead account.
- In the Challenge section at the bottom of this page, select Log into a Developer Edition from the picklist.
- On the login screen, enter the username and password for the Developer Edition you just set up.
- On the Allow Access? screen, click Allow.
- On the Want to connect this org for hands-on challenges? screen, click Yes! Save it. You are redirected back to the challenge page and ready to use your new Developer Edition to earn this badge.
Now that you have a Salesforce CPQ-enabled org, you’re ready to learn how to create product rules in Salesforce CPQ.