What it requires. An active procedure version's element count approaches the documented default of 130 elements per version (raisable to a documented maximum of 200 by a Salesforce support case, assessed individually for performance impact).
Why it matters. [doc] At the cap the next pricing change fails with a hard error - "Delete a pricing element and try again" (KB 005385232) - mid-change, with a support request as the only relief: the case goes to the Revenue Cloud Feature Activation team and is assessed individually for performance impact. The ceiling is documented rather than open-ended: Salesforce Pricing Limits gives pricing elements per pricing procedure as default 130, maximum 200, and the same page caps a pricing procedure's runtime at a one-minute default and a two-minute maximum, which tightens with element count. Findings state the default, the documented maximum and the support-case path, and never promise that a particular increase will be granted.
How to fix it. Consolidate redundant elements, split map-heavy elements, move mapping logic into decision tables, or route strategies through a plan. Where the design genuinely cannot be simplified, the support case is the documented path to a higher limit, up to 200.
Source. Salesforce KB 005385232; Salesforce Pricing Limits
Is this rule worth checking?
Votes and comments are published here. We read them, and we publish what we change with the reasoning — a vote does not move a rule on its own.