First, the 2026 context
Salesforce CPQ (the managed package formerly called Steelbrick) is end of sale, not end of life. Salesforce no longer sells new CPQ licenses to new customers. Existing customers can keep using it, renew, add users and receive support. New feature investment has moved to Revenue Cloud Advanced (RCA), which uses an attribute-based catalog and constraint-based configuration instead of SKU bundles and product rules. Salesforce has announced no end-of-life date and no forced migration.
The practical effect depends on where you are:
- If you run CPQ today, everything below still applies.
- If you are designing a large new rule set, ask whether that effort should go into RCA instead.
- Either way, a clean product model (the bundles, options and compatibility tables you define) carries over better than a pile of one-off rules.
Bundle anatomy
| Object | Role |
|---|---|
| Bundle (parent product) | The configurable item the rep adds to the quote |
| Features | Groups of options on the configuration page (for example "Power", "Mounting"), with min/max option counts |
| Product options | Child products with quantity, required, selected-by-default and quantity-editable settings |
| Option constraints | Simple dependency or exclusion between two options |
| Configuration attributes | Fields the rep sets during configuration (size, color, region), often used in rule conditions |
The four product rule types
| Type | What it does |
|---|---|
| Validation | Shows a message about a problem the rep must fix before saving the configuration or quote |
| Alert | Shows a message the rep can acknowledge and ignore |
| Selection | Adds, removes, hides or shows options during configuration, or adds products to the quote |
| Filter | Limits which products appear in a feature that uses dynamic selection |
A product rule record is mostly a container. The behavior comes from the records attached to it:
- Error conditions: the tests that decide whether the rule fires.
- Actions: what selection and filter rules do.
- Lookup queries: let one rule read its outcomes from a data table.
- Configuration rules: attach the product rule to specific bundles.
Summary variables, which roll up values across quote lines, are often used in conditions as well.
Scope and evaluation events: when rules really run
Scope decides where a rule runs: Product (the configuration page) or Quote (the quote line editor). It runs in one place, never both. Evaluation event decides when. Not every rule type runs at every event, which is the most common reason a rule "doesn't work."
| Scope / event | Occurs when the user... | Rule types evaluated |
|---|---|---|
| Product / Load | Opens the configuration page | Selection, Filter |
| Product / Edit | Changes options or attributes marked Apply Immediately (or clicks Apply Rules) | Selection, Validation |
| Product / Save | Saves the configuration | Alert, Validation |
| Quote / Load | Returns to the quote line editor | Selection |
| Quote / Save | Saves or quick-saves the quote | Alert, Validation |
- "Always" means "all applicable events," not every moment. An Alert rule set to Product/Load never fires.
- Selection rules never run on Save. If you rely only on the Apply Rules button, a selection rule that enforces technical validity may never run.
- Give Validation rules the Always event, so Save acts as the final check.
- Use Evaluation Order in steps of 10 to sequence selection rules that check and uncheck the same options.
Worked example: one compatibility requirement, three designs
This example is illustrative. A bundle offers three motor sizes and two gearboxes, and the large motor requires the heavy-duty gearbox.
- Option constraint: make the heavy-duty gearbox dependent on the large motor. This is the simplest design, and it fits when it is a single pairwise dependency.
- Validation rule: the error condition is "large motor selected AND standard gearbox selected." The message says: "The 15 hp motor needs the HD gearbox. Change gearbox to HD-200." Scope is Product and the event is Always. This design fits when the rep should make the choice consciously.
- Selection rule: when the large motor is chosen, select and lock the heavy-duty gearbox. Use the Edit event, with Apply Immediately on the motor options. This design fits when there is only one valid answer.
When the same pattern repeats across dozens of products, put the motor-to-gearbox combinations in a lookup table and use one rule with a lookup query. One rule reading a table is easier to maintain than forty near-identical rules, and product management can own the table.
Design rules that keep the model maintainable
- Rationalize the catalog before encoding every exception. Rules multiply around SKUs nobody sells.
- Prefer option constraints for single pairwise dependencies, and lookup tables for matrices.
- Name rules by intent, for example "VAL – Motor 15hp requires HD gearbox", and record the business reason in the description.
- Write messages that tell the rep exactly what to change.
- Use the narrowest evaluation event that works. Too many Always or Edit rules on a large bundle slow the configurator.
- Keep a regression set of saved configurations that exercises every rule. Run it after every rule or product change, because a new rule can conflict with an old one.
Testing checklist
- Every rule fires in the scope and event you intended (check the table above).
- Each valid configuration saves with no spurious alerts.
- Each invalid configuration is blocked with a message that tells the rep how to fix it.
- Amendments and renewals of existing quotes behave correctly under the new rules.
- Partner users (in an Experience Cloud portal) see the same rule behavior as internal reps.
When product rules are the wrong tool
Product rules are not the right tool for every kind of logic:
- Pricing logic: belongs in price rules, discount schedules or the quote calculator plugin.
- Engineering logic that needs geometry: clearances, run lengths and layouts are better handled by a visual or spatial configurator that returns a valid selection to CPQ.
- New implementations in 2026: also evaluate RCA's constraint-based configurator, which replaces many product-rule patterns with declarative constraints.
Where RenderDraw fits
RenderDraw's Product Configurator adds a guided, visual front end to configuration. A linked Product Feature Model can own option constraints, or an external CPQ can keep its own rules and commercial logic. Submissions are validated on the server before the selection moves on to pricing and quoting. RenderDraw also offers a Revenue Cloud integration. Book a demo, or read the Salesforce CPQ implementation guide and the Revenue Cloud Advanced guide.
