[SalesForce] Disable SteelBrick/CPQ Trigger from running in current trigger context

The first thing to do is remove the current try/catch block you have in captureFuture if it is just a comment of //do error handling here as you show in the question. It will be catching and then ignoring any potentially useful details as it is shown. That is of course assuming the method actually appears as it does in the question. If you've got meaningful exception handling then feel free to disregard this step.

Once you know that any exceptions will actually be recorded use the Developer Console to capture the debug logs. You will see two log entries when inserting a bt_stripe__Transaction__c record. One for the trigger transactions, and one a short time later for the future method transaction.

Open the one for the future method and observe what is actually occurring.

Within your trigger, you can pass a list of bt_stripe__Transaction__c Id's to the future method. Ideally the transactionFactory method will also be able to work with a collection of Id's rather than one at a time. As a guess you might only need a single call to commitWork() for all the IDs.

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.