Pricing·Advanced·8 min·Updated 2026-10-05
Why a pricing procedure that works in one org returns nothing in the next
Pricing is not one artefact but five, and moving a subset produces a procedure that runs and prices nothing.
A pricing procedure is the visible part. Underneath it sit the context definition it reads, the decision tables it calls, the adjustment schedules it applies and the price book entries it starts from. Move the procedure alone and it executes cleanly, returns nothing, and looks like a pricing bug.
Two details make this worse than an ordinary dependency problem.
First, procedure steps can carry hardcoded record identifiers. Identifiers do not survive an org change. A step that applies an adjustment schedule by identifier silently applies nothing in the target org, and the configuration looks identical in both.
Second, the procedure that runs is the compiled version, not the source you edit. On one org the source carried 81 standard steps and the compiled version carried 128. Inspecting the source to verify a migration proves nothing at all.
The only verification that means anything is repricing a real quote in the target org and reading the line totals.