Steelbrick/Salesforce CPQ - Alter a Price Rule if another one is running?

You should use the extra "lookup tables" functionality available within Price Rules.

How this works is, in addition to the header-level rule attributes, conditions for firing, and actions taken when true, is that there's also a "lookup query" you can define that points to a custom object and matches one value to another, similar to SQL (or SOQL). So you could create an object called "Suite Pricing" that has records for each product, and fields for each scenario that store a discount percent (e.g. field 1 is "Suite - 5%", field 2 is "Annual - 10%", field 3 is "Suite + Annual - 15%").

You would need 2 lookup queries: One to match the product on the quote to the record on the table, one to match the value to the scenario. Your condition is likely to fire all the time or if the quote line product family = your suites, and the action would be to populate that discount onto the quote line (or quote is fine, if you will only ever have 1 suite on 1 quote). Finally an additional rule or action on the same rule would inject the value of "price minus discount" into the pricing sequence, likely "special price" (and then an additional action would also set the "special price type", to any non-blank value, to make sure the system picks up your special price).

The one final consideration is to make sure you rules, and actions within rules, fire in the appropriate sequence. This should be easy to define based on your use case, but must be specified in the appropriate fields to prevent unwanted/unpredictable actions from occurring within your quoting sequence.

Hope this makes sense.

Thanks,

Christopher Hickman

Edit: Another possibility to consider would be to define separate SKUs for your "everything and the kitchen sink" bundles, set to be non-configurable (locked into selecting all) and discountable only at the parent level, or even not at all at the product level (in a discretionary sense; requiring a quote-level discount only spread across the entire "cart"). Depending on your/the client's views on "SKU proliferation" you may prefer the former method even though it is more complex to set up and requires more data maintenance (since the custom object records are in addition to products, price books, and product options/etc.) but tracking offering this way may actually be more natural to the organization if they think about things in a standard/enhanced/deluxe/ad-hoc way...the former method does provide that data but in a less straightforward way than just having 2 SKUs.