Salesforce Product Rule Testing
Salesforce product rule testing validates the Salesforce CPQ rules that decide what a rep is allowed to configure — validation and alert rules that block or warn on invalid combinations, selection rules that add, remove, show or hide options, and filter rules that narrow the catalog. It proves that every quote leaving CPQ describes something the business can actually deliver, support and bill.
Product rule coverage is part of the configure-price-quote journeys available for demonstration and proof-of-concept validation.
What product rules control
Product rules (SBQQ__ProductRule__c) encode the configuration logic that product managers would otherwise enforce by reviewing quotes manually. Each rule has a type, a scope, an evaluation event and a set of error conditions. Validation rules stop a rep from saving an invalid configuration and display a message; alert rules display a message but allow the rep to continue; selection rules take actions on product options; and filter rules drive dynamic search filters in the product selection page.
Scope decides where the rule runs — Product scope evaluates in the bundle configurator, Quote scope evaluates across the quote in the line editor. The evaluation event (Load, Edit, Save or Always) decides when. Configuration rules link a Product-scoped rule to the bundles it applies to, and condition logic (All, Any or a custom expression) combines error conditions that test quote, quote line, configuration attribute or summary variable values. Separately, option constraints on a bundle express simpler dependencies and exclusions between options.
Because these parts are configured on different records and objects, a rule can look correct on its own and still fail in combination. That is why product rules deserve their own test coverage within configure-price-quote testing, separate from the pricing logic covered by price rule testing.
Rule types and what a test must prove
Each product rule type fails differently, so each needs its own style of assertion.
| Rule type | Intended behavior | Core assertion |
|---|---|---|
| Validation | Blocks save or configuration when conditions are met | The message appears, the save is prevented, and a valid configuration still saves |
| Alert | Warns but lets the rep continue | The message appears at the right event and does not block the save |
| Selection — add or remove | Automatically selects or deselects options | The resulting quote lines exist or are absent after the rule fires |
| Selection — enable or disable | Makes options selectable or locked | The rep cannot select a disabled option, including through quantity edits |
| Selection — show or hide | Controls option visibility in the configurator | Hidden options are neither visible nor present on the saved quote unless intended |
| Filter | Narrows products in search or dynamic option lookup | Only products matching the filter are returned for that context |
| Option constraint | Requires or excludes options relative to another option | Constrained options respond to the controlling option's selection |
Where configuration logic breaks
A broken product rule rarely stops a quote. More often it lets an unsupportable configuration through or forces reps into workarounds.
Missing configuration rule link
A Product-scoped rule is active but not linked to a new bundle through a configuration rule, so it never evaluates for that bundle.
Event mismatch
A validation rule set to evaluate on Save allows reps to build an invalid bundle for several steps before being blocked, or is skipped by a save path it does not cover.
Rule loops
Two selection rules add and remove the same option in response to each other, leaving the configurator unstable or the final state order-dependent.
Scope confusion
A rule written for the configurator is needed across the quote, so combinations built from separate bundles on one quote are never validated.
Testing product rules in the configurator
SyntraFlow is designed to drive the CPQ configurator and line editor the way a rep does, because product rule behavior depends on the sequence of clicks and events.
Load the bundle
Open a controlled bundle from the product selection page and assert any Load-event rules have already selected, hidden or disabled the expected options.
Make a triggering selection
Select the option or set the configuration attribute that satisfies the rule's error conditions, and confirm Edit-event and Always-event rules respond immediately.
Attempt an invalid combination
Deliberately build a configuration the business prohibits and confirm the validation message text and that the save is prevented.
Correct and save
Resolve the invalid selection and save, confirming the valid configuration is accepted and the quote lines match the configurator state.
Reconfigure the saved bundle
Reopen the bundle from the line editor and change a controlling option, proving rules re-evaluate on reconfiguration and do not leave orphaned options.
Validate across the quote
Add a second bundle or standalone product and confirm Quote-scoped rules evaluate the combination, not just each bundle in isolation.
Negative paths and edge cases
The most useful product rule tests are the ones that try to get around the rule.
- Changing option quantity to zero rather than deselecting it, to see whether selection and validation rules still recognize the option as removed.
- Cloning a quote line or quote that was saved before a new validation rule was activated, and confirming the rule applies on the next save.
- Editing quote lines through a mass update or integration rather than the configurator, where Product-scoped rules do not run.
- Using configuration attributes with blank, default and boundary values in conditions.
- Amending a contract with an existing bundle to add an option the rules now exclude, which ties into amendment testing.
- Running the configurator as a rep whose profile lacks access to a field used in an error condition.
- Deactivating a rule and confirming no residual option state or message remains.
Test data and ownership
Product rule tests need a small, stable catalog that mirrors real bundle structure: bundle parents with features and options, option constraints, configuration attributes, the product rules and their conditions and actions, and the configuration rules that link them. Summary variables used in conditions must be present, and product records must be active in the price book used by the test quote. These are data records, so they are usually migrated with data tooling rather than deployed as metadata; CPQ test data covers keeping them consistent across sandboxes.
Ownership matters too. Product managers usually define what is valid; CPQ administrators encode it; sales operations hears from reps when it is wrong. Writing the rule expectations as named scenarios — a prohibited pair, a required dependency, a region-specific restriction — gives all three groups a shared definition of correct and makes failures easy to triage.
Suggested test scenarios
A starting set of product rule scenarios that covers each rule type and the most common workarounds.
| Scenario | What it proves |
|---|---|
| Prohibited option pair | A validation rule blocks the save and shows the designed message |
| Required companion option | A selection rule adds the companion when the controlling option is chosen |
| Region-restricted product | A filter or validation rule excludes the product for accounts in that region |
| Alert on non-standard term | The warning appears and the rep can still proceed |
| Reconfigure after save | Rules re-evaluate and remove dependent options when the controller changes |
| Cross-bundle conflict | A Quote-scoped rule catches a combination split across two bundles |
| Quantity-zero workaround | Rules treat a zero-quantity option as the business intends |
Regression and evidence
Each run is designed to record the configurator state after every action, the messages displayed, whether each save succeeded, and the final quote lines. That evidence shows product management exactly which configuration was attempted and how CPQ responded, rather than a pass or fail with no context.
Product rules change whenever the catalog does — new bundles, retired options, new regions. Every such change can break an existing rule's link or conditions. Rerunning the suite through Salesforce test automation after catalog updates and CPQ package upgrades, as part of CPQ regression testing, keeps invalid configurations from reaching orders and fulfillment.
Related pages
Business Processes
The full library of Salesforce business process tests product rules belong to.
Price Rule Testing
The companion rule type that sets and adjusts prices on configured lines.
Configure-Price-Quote Testing
The end-to-end CPQ journey in which product rules govern configuration.
Salesforce CPQ Testing
Broader coverage of the CPQ package, configurator and quote line editor.
CPQ Test Data
Seeding bundles, options and rule records consistently across sandboxes.
Amendment Testing
Where existing bundles meet current product rules during mid-term changes.
Product Rule testing FAQs
What is Salesforce product rule testing?
It is testing the Salesforce CPQ product rules that govern configuration — validation, alert, selection and filter rules, along with option constraints. Tests confirm that invalid combinations are blocked or flagged, required options are added, restricted products are filtered out, and valid configurations still save cleanly.
Why do product rules need to be tested through the configurator?
Product rule behavior depends on evaluation events such as Load, Edit and Save, and on the order in which a rep makes selections. Checking the rule records alone cannot show what the rep experiences. Driving the configurator reproduces the real event sequence and the resulting quote lines.
What is the difference between Product scope and Quote scope?
Product-scoped rules evaluate within the bundle configurator and apply to bundles linked through configuration rules. Quote-scoped rules evaluate in the quote line editor across all lines on the quote. A combination that spans two bundles is only caught by a Quote-scoped rule, so both scopes need scenarios.
Can product rules be bypassed?
Configurator rules do not run when quote lines are created or edited outside the configurator, such as through data loads or integrations, and some workarounds like zero quantities may not be treated as deselection. Testing these paths shows where additional validation, such as a standard validation rule or a Quote-scoped rule, is needed.
How often should product rule tests run?
At minimum after every catalog change, product rule change and CPQ package upgrade, and ideally as part of each deployment pipeline. Because rules are data records moved between orgs, running the suite after data migrations is as important as after metadata deployments.
Is product rule testing available in SyntraFlow today?
Product rule scenarios are part of the configure-price-quote coverage available for demonstration and proof-of-concept validation. The bundles, rules and scopes in scope are confirmed per engagement.
Keep invalid configurations off your quotes
Turn your product rules and bundle logic into repeatable configurator scenarios in a short working session.