Scaling past the procedure ceiling

The problem

A growing catalog pushed one pricing procedure to 128 elements against an observed ceiling of 130. The next offer had nowhere to go.

Context

Several distinct commercial offers, each with its own pricing logic, all living in the single default procedure.

Recommended architecture

Split by offer: an orchestrator that selects a procedure, and one procedure per offer, each with its own element budget. This also makes the logic of an offer readable on its own instead of interleaved with every other offer's steps.

Implementation

Build the per-offer procedure first and prove it on a quote, then wire the orchestration. The two org settings that enable it are reversible — which matters, because the next point explains why you may need to reverse them.

Trade-offs

More procedures means more to deploy and more to keep aligned. The cheaper move, if the catalog allows it, is to remove elements rather than add capacity: a decision table added by reflex for a price that has no condition is pure ceiling consumption. Put flat prices on the PricebookEntry and the ceiling recedes.

Watch out

• Rolling the orchestration settings back did not clear an unrelated configurator error on the same org, which proved the error was not caused by pricing at all. Changing two things at once makes this kind of elimination impossible — change one, observe, then change the next.
• The procedure that runs is the compiled _Auto version. Counting elements on the source tells you nothing about how close to the ceiling you are.

Salesforce components