Beyond SteelBrick: A Constraint-Based Path Forward for Salesforce CPQ Customers

Beyond SteelBrick

A Constraint-Based Path Forward for Salesforce CPQ Customers

Executive summary

We start with our conclusion: if you built your CPQ implementation on Salesforce's SteelBrick-derived managed package, you are already past the point where rules-and-conditions logic was ever going to hold up under the complexity you've likely added to it, and the vendor decision you're facing — legacy CPQ's End-of-Sale, no supported migration path to its successor — is a genuine opportunity to fix that, not just a forced upgrade to absorb.

We are not asking you to rip out your CPQ implementation. Salesforce's own product line already forces that conversation on a timeline of its choosing. What we're offering is a constraint-based reasoning layer — one that can sit alongside what you have today as a deterministic validation and pricing brain, or become the foundation of what you rebuild toward, depending on where you are in that forced transition. Either way, the argument for it doesn't depend on trusting a vendor's roadmap slide. It rests on specific, verifiable ways that a rules engine — any rules engine, including a well-run SteelBrick org — runs out of road as configuration and pricing logic gets genuinely interdependent, illustrated below with real CPQ mechanics, not hypotheticals.

Where you stand today

Salesforce's legacy CPQ — the SteelBrick-derived managed package most Salesforce customers are running — entered End-of-Sale in March 2025: no new licenses, no further product investment, existing customers keep support and renewals. Salesforce isn't exiting CPQ; it's retiring this specific product in favor of Revenue Cloud Advanced, built natively on the Salesforce core platform. But there is no supported migration path from the old package to the new one — moving means a genuine rebuild, not an upgrade, typically estimated at twelve to twenty-four months and two to three times the cost of the original implementation. Salesforce has not announced a formal End-of-Life date; outside analyst estimates cluster around 2029–2030, and we'd treat that as an estimate, not a commitment you can plan around.

That puts you in a specific position: your current system still works, support hasn't disappeared, but the product line underneath it has stopped moving forward, and the eventual successor is a different system entirely, not a later version of the one you have. Most organizations in this position start asking a broader question than “which CPQ product should we move to next” — they start asking whether the underlying approach, rules-and-conditions logic reacting to whatever a rep just clicked, was ever going to scale with how complex their product and pricing structures have become. We think that's the right question, and we think the honest answer is no — not because SteelBrick is poorly built, but because of what a rules engine structurally can and can't do, which the rest of this paper makes concrete.

What configuration is — and where it isn't

We should be precise about what we mean by a configuration problem, because the term gets applied loosely, and loose use of it is exactly how organizations end up buying constraint technology they don't need or dismissing it where they do.

A configuration problem exists wherever multiple interdependent decisions, owned by different disciplines or tools, must be reasoned about jointly — where a choice in one place changes what's valid somewhere else, and getting the combination right (or knowing when it's wrong) requires holding the whole picture at once, not evaluating each piece in isolation. A data center rack's server selection determines its power draw; power draw determines how much PDU capacity is needed; PDU capacity, in turn, constrains how much rack space is left for the servers you were trying to add in the first place. None of those three decisions belongs to one discipline, and none of the standard single-purpose tools — a server sizing sheet, a power calculator, a floor-plan spreadsheet — owns the combination.

It is just as important to say where this doesn't apply. If a task reduces to a single-domain verdict that an established tool already owns — a structural stress calculation, a shipping-rate lookup — calling it a configuration problem and reaching for a constraint engine adds nothing. The advantage we're describing lives specifically in the coupling between decisions, not in any one decision being hard on its own. We'll be concrete about which parts of CPQ logic have this shape as we go, rather than implying all of it does.

Why rule-based CPQ hits a ceiling

Every mechanism a Salesforce CPQ (henceforth just CPQ) admin has available — Product Rules, Price Rules, Summary Variables, Lookup Queries — is fundamentally a reactive validator: something changes, a condition gets checked, an action fires or an error blocks the save. That's a perfectly workable model for simple, independent checks. It becomes a real liability once your configuration or pricing logic has the coupled, multi-party shape described above — which, for any business selling genuinely configurable products or negotiating genuinely layered pricing, is not a rare case. Four patterns show up repeatedly in real CPQ implementations.

A rule can silently fail to fire — and the save still succeeds>

CPQ evaluates rules in fixed stages (Product Rules run on Load, Edit, or Save), and within one stage, every rule's condition is checked against a single snapshot of the data before any rule's action executes. If Rule A adds a required component and Rule B's condition depends on that component being present, and both rules share a stage, Rule B's condition is checked one step too early — it never sees what Rule A just added. The quote saves. No error appears. The rep has no idea a required part is missing until someone downstream notices, or a customer does. Salesforce's own documentation names this as a known gotcha, and the only fix is an admin correctly hand-sequencing which rules run in which stage — a discipline that must be maintained correctly forever, across every admin who ever touches the org.

A constraint-based engine doesn't have stages in this sense at all. A dependency between two requirements resolves the moment the underlying value changes, automatically, regardless of which order the rules happen to be declared in. There is no equivalent failure mode to design around, because there is no snapshot to go stale.

Genuinely structural requirements don't fit the reactive-rule shape

Take a real infrastructure requirement: a rack's power system must provide 2N redundancy — two fully independent power feeds, each one, on its own, sized to carry the entire rack's load (not half of it split evenly), with an 80% continuous-load derating margin on top. That's not one threshold check; it's a relationship spanning multiple components at once, checked twice, independently. Expressing that correctly in a reactive rules engine is enough contortion that, in practice, we regularly see it left unmodeled entirely — not because admins don't understand redundancy, but because the tool doesn't have a natural way to say it. A constraint engine, by contrast, is built to reason across exactly this kind of multi-entity relationship as a first-class case, not a workaround.

Some problems need a solver, not a validator — and CPQ has neither>

Picking a workable set of components — for instance, however many PDUs, of whatever models, are needed to jointly cover a rack's power load and fit in whatever rack-unit slots are left after servers, cooling, and networking gear — is a combinatorial problem: the right combination might satisfy one constraint while quietly violating the other, and finding one that satisfies both isn't something you check after the fact, it's something you have to search for. Nothing in CPQ's architecture does this. Every mechanism it has is a validator or a static filter; there is no search or optimization primitive anywhere in the product. A rep guesses a combination, saves, gets told they're short on capacity or over on slots, and tries again — with the system offering no help narrowing the space. This is a different kind of gap than the staging bug above: it isn't “CPQ does this awkwardly,” it's “this class of problem is outside what a rules validator can ever do,” regardless of how well it's configured.

Aggregate logic is fragile in ways that don't show up until it's wrong>

Volume discounts and capacity checks in CPQ typically run through a Summary Variable — a hand-configured sum across quote lines, scoped by whatever filter an admin set up. That scoping is doing real work, and it's easy to get subtly wrong without any visible symptom: a discount meant to apply once a customer's combined Compute-plus-Storage commitment crosses a threshold, for instance, will silently misfire if a later change splits the discount tiers by product family without also splitting the underlying aggregate — a customer buying 60 units of each would still clear a 100-unit “Compute-only” threshold they never actually qualified for. Nothing in CPQ catches this; the quote just calculates a discount nobody intended. A constraint engine defines the aggregate's scope once, as part of the relationship itself, rather than assembling it from a filter and a separately-maintained condition that a human must keep in sync by hand across every future change.

Two more patterns don't fit the bug category at all — they're not something a differently-configured rule could fix, no matter how careful the admin.

New product categories can't appear on their own — someone has to go back into Setup>

Salesforce's own guidance for migrating off CPQ names “dynamic bundles” as a feature that doesn't map to what comes next — worth taking at face value, because the underlying limitation is real. A bundle's Features — its option categories, its slots — are fixed, admin-authored metadata, created once in Setup before any Quote is ever configured. CPQ's Dynamic Bundle mechanism can filter which pre-built options are visible within an existing Feature based on a rule; it cannot bring a new Feature into existence at configure time, no matter how the rule is written. If a product line later needs an entirely new category of add-ons for a tier that didn't exist when the bundle was designed, there is no configuration path to introduce it — only a return trip to Setup. A well designed constraint engine doesn't distinguish between visibility and existence this way: a model materializes when the condition for it is true, whether that condition was anticipated at design time or not. This is the same kind of ceiling as the combinatorial gap above — not a rule an admin got wrong, but a category of requirement the platform was never built to express.

The option list never gets smarter as a rep clicks through it>

As a rep adds components that draw against a shared, limited resource — power, weight, a budget cap — CPQ can validate the total against a limit once the rep tries to save, via the same Summary Variable and Validation Rule pattern described above. What it cannot do is narrow the list of remaining selectable options live, in real time, as capacity gets consumed — nothing shrinks, grays out, or disappears to reflect what's still actually available. A rep can keep selecting well past the limit with no feedback at all, then get rejected only at Save, with no guidance on which of their choices to undo. A constraint engine exposes “what's still valid given everything already selected” as a live, continuously updated fact, not a question the rep only gets answered after they've already guessed wrong. This is exactly the same shape of gap Section "One more requirement: is it actually ready for Agentforce?" raises for a conversational interface: a system that only tells you you're wrong after the fact was never built for an interaction that expects to be guided as it goes.

Pricing is a configuration problem too

It's tempting to treat pricing as “just a calculation” once the configuration is settled. In practice, quote-time pricing has exactly the coupled, multi-party shape we defined in Section "What configuration is — and where it isn't" — and CPQ's pricing model shows the same reactive-rule ceiling as its configuration side, with real financial stakes attached.

A representative case: an Enterprise Agreement negotiated by deal desk should override a standard volume-tier discount when both would otherwise apply to the same line. In a typical CPQ org, that precedence exists nowhere as a declared rule — it's an emergent property of which rule an admin happened to rank higher, backed by an offline convention deal desk verifies by hand before a quote goes out. There is nothing in the system stating, “EA always wins.” That's not a hypothetical audit risk; it's exactly the kind of ambiguity that produces a wrongly stacked discount, and wrong stacking is a revenue-recognition problem, not just a worse deal. Layered on top, many orgs enforce a margin floor — blocking a quote if the final net price would fall below cost by too much — through custom plugin code that runs after the declarative pricing rules, meaning that check exists nowhere a business user, or an auditor, can read it.

A constraint-based approach makes both an explicit, inspectable part of the model — stated once, as a real precedence relationship or a real margin constraint, not reconstructed after the fact from rule-ranking order and a spreadsheet someone in deal desk maintains.

Worth naming directly: we did the work of verifying every mechanism described in this section — evaluation staging, Summary Variables, rule ranking, plugin-based margin checks — against current Salesforce CPQ documentation and mechanics. This isn't a caricature of a competitor's product; it's how CPQ actually works, described precisely enough that a Salesforce admin reading this would recognize every example.

What a constraint server requires

None of the above is solved by writing “smarter rules.” It requires a different kind of engine, and it's worth being specific about what that engine has to guarantee, because these properties are exactly what a reactive rules system doesn't have by construction:

Correctness — every result the engine returns must actually satisfy every constraint in the model; a plausible-looking answer that quietly violates one requirement is worse than an explicit error.
Completeness — if a valid configuration exists, the engine has to be able to find it, not give up and report failure on solvable problems.
Propagation — a choice made anywhere in the model should immediately narrow what's still valid everywhere else, live, not just at save time — this is the mechanism that makes the staging bug in Section "Why rule-based CPQ hits a ceiling" structurally impossible rather than merely rare.
Consistency — the engine must be able to tell the difference between “no valid configuration exists from here” and “we haven't found one yet,” and explain which constraints are in conflict when it can't proceed.
Backtracking and search — for genuinely combinatorial problems (Section "Why rule-based CPQ hits a ceiling" PDU-selection example), the engine needs to actually explore the space of valid combinations, not just validate whichever one a rep happened to guess.

These are the requirements we designed Predictika's engine against from the start — not retrofitted onto a rules architecture after the fact, which is the difference between a system that reasons and one that reacts.

Worth being precise, too: not every system that calls itself “constraint-based” actually has all five of these properties, or has them for the same reasons — Oracle, Tacton, and Configit all use that label as well, and differ from each other and from us in real, patent-documented ways. A fuller comparison across several well-known configuration engines is in a separate paper, “Not All Constraint-Based Systems Are the Same,” listed below.

One more requirement: is it actually ready for Agentforce?

"Why rule-based CPQ hits a ceiling" diagnosed a specific staging bug: CPQ tests every rule's condition in a stage against one snapshot before any action fires, so a rule depending on another rule's output in the same stage can silently miss it. That's a real production risk today, with a rep clicking through a wizard in the order Salesforce built it to be clicked. It becomes a different kind of risk the moment you put Agentforce in front of the same system — which is exactly the direction Salesforce's own roadmap is heading.

An Agentforce conversation doesn't ask questions in the order a wizard was authored to ask them. A customer might state a downstream requirement before an upstream one, mention two things in the same breath, or revise something from three turns back. Worth asking directly, whatever's actually running underneath your Agentforce configuration flows today: can a rep or customer say what they need in whatever order it comes up and still get the right answer — or does it quietly still need to walk them through the same guided sequence your CPQ already uses, just with a chat window on top? An engine that only reaches the right answer when information arrives in a specific order will either force the conversation into that fixed sequence — defeating the point of talking to it naturally — or produce results that silently depend on how the conversation happened to unfold, which is a much harder kind of bug to catch than a wizard ever produced.

This is the same failure mode as Section "Why rule-based CPQ hits a ceiling" staging bug, one level up: the architecture wasn't built around a fixed sequence to begin with, and a fixed-sequence assumption running underneath a flexible conversational interface is exactly where it breaks. A constraint-based engine built around automatic, change-triggered propagation — a constraint re-fires the moment something it depends on changes, regardless of what order the underlying facts arrived in — doesn't have this failure mode to design around, for the same structural reason it doesn't have Section "Why rule-based CPQ hits a ceiling" staging bug: there's no snapshot, and no fixed sequence, to go stale. (See “Requirements for a Constraint Server Behind an LLM Front End” in Suggested Further Reading — the same architecture question, worked through in full.)

The path forward — not a rip-and-replace

We're not proposing that you tear out a working CPQ implementation on our say-so. The realistic path we'd recommend depends on where you are in the transition Salesforce has already put you on:

If you're staying on legacy CPQ for now —a constraint-based reasoning layer can sit alongside your existing implementation as a deterministic validation and pricing service.

The specific coupled logic described in Sections 3 and 4 — structural sizing, combinatorial selection, aggregate scoping, discount precedence — gets modeled and reasoned about correctly, without touching the rest of your working SteelBrick org. This is the lowest-risk entry point, and it's where we'd suggest starting.

If you're already planning the Revenue Cloud Advanced rebuild — Salesforce itself has told you this is a from-scratch effort, not an upgrade.

That's precisely the moment to decide what the underlying reasoning engine should actually be, rather than defaulting to whatever the new product ships with. A constraint-based foundation, modeled once with correctness and completeness as first-class guarantees, is a materially different starting point than another generation of reactive rules — and this is where the greater business risk, and the greater available upside, both live.

Either way, the argument doesn't ask you to take our word for how CPQ behaves. Every example in this paper is something a Salesforce admin on your own team could reproduce in a sandbox this afternoon. We'd rather start the conversation there than with a pitch deck.

Suggested Further reading

" You May Not Realize It, But Your Business Has a Configuration Problem " – explains how to determine whether you have a complex enough configuration problem.

" Complex Product Configuration Requires a Constraint-Based Approach " — the technical case for constraint-based configuration, with architecture and object-model detail.

" The Business Case for Constraint-Based Configuration " — a condensed overview for CIO/COO/CRO audiences.

" Requirements for a Constraint Server Behind an LLM Front End " — the correctness/completeness/propagation/consistency requirements from Section "What a constraint server requires", in full technical depth.

" Pricing Is a Configuration Problem " - A Constraint-Based Approach to Enterprise Quote-Time Pricing, the Section "Pricing is a configuration problem too" argument, developed at length with a Google Cloud worked example.

" Guiding AI Agents to Reason Correctly " – shows how Predictika constraint engine can act as a reasoning co-pilot to existing AI Agents to ensure correct behavior.

" Not All Constraint-Based Systems Are the Same " – a broader comparison of several well-known constraint-based configuration engines (Oracle, Tacton, Configit), for readers weighing more than one constraint-based vendor, not just a rules-based one.

About Predictika

Predictika.ai builds a patented constraint-based configuration and pricing engine rooted in a research lineage that runs from Xerox PARC through Selectica, the enterprise CPQ pioneer whose customers included IBM, Cisco, Dell, GE, Hitachi, Disney, and AT&T. Predictika's declarative modeling language, LVML, carries forward a distinctive prototype object-oriented architecture in which sub-entities inherit both parameters and constraints from the structures that contain them — a direct technical descendant of that PARC lineage. The company holds patents covering deterministic validation of LLM-driven systems (U.S. 11,544,475 and 11,914,970).

About the author

Dr. Sanjay Mittal is the founder and CEO of Predictika.ai. His work in constraint-based AI began at Xerox PARC and was first commercialized through Selectica, a company he founded in 1996 and led its IPO in 2000. At Selectica he helped build one of the first enterprise CPQ platforms architected for the internet. Predictika continues that lineage, applying constraint reasoning to configuration and pricing problems across data center infrastructure, cloud pricing, and other domains where interdependent decisions must be reasoned about jointly.