Skip to main content
Join the Agentforce Hackathon on Nov. 18-19 to compete for a $20,000 Grand Prize. Sign up now. Terms apply.

Make Rules for Specific Bundles

Learning Objectives

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

  • Create a summary variable to sum quantities of select products.
  • Set up a product rule that applies to only one bundle.
  • Describe the challenges of testing product options in error conditions.

A Bundle That Plays by Its Own Rules

You already know that product rules are meant to help sales reps get the right products onto the quote. But sometimes that help is only needed when reps are in the middle of configuring specific bundles.

For example, imagine that you have a bundle named Telecommuter Workstation. This bundle is a computer meant for businesses that need to support a growing remote workforce. It has some required options for a keyboard, mouse, and monitor; and a few choices for headphones, cameras, and microphones.

Product Configuration page for Telecommuter Workstation

It’s a basic bundle, but it’s designed that way so it can be shipped as quickly as possible. That said, sales reps have been making a mistake by selling some configurations that don’t actually have a microphone, leaving some workers without a voice on virtual meetings. So, you need a rule specific to the Telecommuter Workstation that prevents sales reps from selling the bundle without some kind of microphone.

For this example, you can create a rule that operates only within the context of the Telecommuter Workstation. You don’t want the rule to run when configuring other bundles, and you don’t want the rule to run on the Quote Line Editor. You are intentionally limiting the scope of the rule. As you see throughout this unit, there are things you have to do to make sure the rule works correctly within this limited scope.

Summary Variable

The product rule you want to create really just tests to see if there are no microphone-related options selected. So you need to know how many are actually selected. You could use that information in the error condition, triggering the rule if the number is zero. Thankfully, CPQ has a tool for counting options based on some criteria, and that tool is called a summary variable.

The job of a summary variable is simple: Look at a set of data, and summarize it down to a single numeric value. For example, you can:

  • Count the number of all “WiFi Access Point” assets on an account.
  • Find the maximum discount percent across all lines on a quote.
  • Sum the quantity of selected options that have a product code that ends in “MIC” within a bundle.

It’s the last one that you need to know for your rule. We’ve conveniently named the AW Computing products so that you can identify any that include a microphone just by looking at the last three letters in the product code. So before you create your rule, let’s create the summary variable to sum microphones. You start by navigating to the Summary Variable tab.

  1. From the navigation bar, click Summary Variables.
  2. Click New.
  3. For Variable Name, enter Microphone Sum.
  4. For Target Object, choose Product Option.
    This tells CPQ to focus on summarizing Product Option data, which is great because you intend for the rule to run when configuring a bundle. You would only choose Quote Line when a rule is meant to run on the Quote Line Editor. Asset and Subscription data can be used for rules that run in both places.
  5. For Aggregate Function, choose Sum.
    This tells CPQ how to summarize the data. In this case, you summarize by adding together values into a sum. Specifically, you sum the Quantity field. For that reason you leave the Aggregate Field field set to Quantity.
    You’re almost done, but you don’t want to sum the quantity of every single product option, only those that are microphone-related. So you need to create a filter.
  6. For Filter Field, choose Product Code.
  7. For Operator, choose ends with.
  8. For Filter Value, enter MIC.
    Now the data CPQ summarizes is limited to only microphone-related options. There are a lot of ways to filter data in summary variables, this is just a simple and convenient example.
  9. Click Save.

It may not seem like much, but you now have a powerful tool in your back pocket. It comes in handy when you create the error condition of the product rule.

Create a Bundle-Specific Rule

You’re now ready to create the rule that stops reps from selling workstations without microphones. You start by navigating to the Product Rules tab.

  1. From the navigation bar, click Product Rules.
  2. Click New.
  3. For Product Rule Name, enter Prevent missing microphones.
  4. For Type, choose Validation.
  5. For Scope, choose Product.
    Remember, this is how you tell CPQ the rule should run during product configuration.
  6. For Evaluation Event, choose Save.
  7. Check Active.
  8. For Conditions Met, choose All.
  9. For Message, enter Please choose an option that includes a microphone.
  10. Click Save.

Good start, you have the basics done. Now it’s time for a condition. You want to perform a test to check if the summary variable is equal to zero.

  1. In the Error Condition related list, click New.
  2. For Tested Variable, look up and choose Microphone Sum.
    Your handy summary variable can be used for as many product rules as you’d like. Now you just have to check if the sum is zero, which you do by setting the next few fields.
  3. For Filter Operator, choose equals.
  4. For Filter Type, choose Value.
  5. For Filter Value, enter 0.
  6. Click Save.

There’s just one last, extremely important step to do. At this point, CPQ doesn’t know that the rule is supposed to apply to the Telecommuter Workstation bundle. You make this association by creating a Configuration Rule record.

  1. In the Configuration Rules related list, click New.
  2. Check Active.
  3. For Product, look up and choose Telecommuter Workstation.
  4. Click Save.

That’s all it takes. For this example you’re only going to create a single Configuration Rule record. But if you had more than one bundle the rule should act on, you would create a Configuration Rule record for each one.

Now that your rule is complete, let’s test it by putting Telecommuter Workstation on a premade quote.

  1. From the navigation bar, click Quotes, then choose the All list view.
  2. Click Q-00040.
  3. Click Edit Lines.
  4. Click Add Products.
  5. Check Telecommuter Workstation.
  6. Click Select.
    By default, the bundle has no microphone-related options selected, which is exactly the condition that should cause the error message to appear. Let’s see if it does.
  7. Click Save.
    The error message should appear. Fantastic, now let’s make sure it doesn’t appear when an option with a microphone is selected.
  8. Check the option for HEADPHONESMIC.
  9. Click Save.
    At this point you should move forward to the Quote Line Editor, well done!

Limits of Testing Product Option Fields

When you create an error condition for a bundle-specific rule you can test summary variables, configuration attributes, and product option fields. For example, you could check the product option field of Quantity to see if it’s greater than 10. The way CPQ handles tests involving product option fields is to cycle through each selected option, performing every test against the option as if it were the only one that exists. This method holds within it two important caveats to remember when making bundle-specific error conditions.

First, CPQ only tests selected options, ignoring anything that’s unchecked. That means it’s impossible to test for something that isn’t selected. That’s why you created a summary variable in the beginning of this unit, so that you could discover if zero microphones were selected. If you didn’t have the summary variable, and you just tried to test if the Product Code field does not contain “MIC” then you would’ve got a bunch of false positives. For example, the keyboard option doesn’t contain “MIC” so the condition would be true, and the rule would fire, even if an actual microphone option was selected.

The second caveat involves testing two separate options in the same rule. For example, imagine you want to test a coffee bundle to see if both “Cream” and “Sugar” options are selected, using these conditions.

  • Product Code = Cream
  • Product Code = Sugar

Because you want both to be true, you need to use “All” for the Conditions Met field. When CPQ gets to the Cream option and performs the tests, the Sugar test will fail. It’s impossible for a single option to be both Cream and Sugar, so the rule will never run.

The workaround is to use a summary variable to count one of the options, such as Sugar. That would give you these two tests.

  • Product Code = Cream
  • Sum of Sugar Options > 0

Now when CPQ gets to the Cream option, both tests can pass, and the rule can fire.

Creating good logic for product rules is sometimes a challenge, so the most important thing you can do after creating a rule is to thoroughly test it. Try testing when you expect the rule to fire, as well as scenarios when it shouldn’t.

Now that you’ve seen how rules work in the context of bundles, in the next unit you investigate selection rules, which are used heavily (but not exclusively) in bundles as well.

Resources

Share your Trailhead feedback over on Salesforce Help.

We'd love to hear about your experience with Trailhead - you can now access the new feedback form anytime from the Salesforce Help site.

Learn More Continue to Share Feedback