Migration·Référence·8 min·Mis à jour le 05/10/2026
Cas d’usage · Pricing
Déplacer une configuration de pricing entre orgs
Pourquoi une pricing procedure qui marche dans une org ne rend rien dans la suivante, et ce qui doit voyager ensemble.
Le besoin métier
Déplacer une configuration de pricing qui fonctionne d’une sandbox vers la production sans la reconstruire à la main.
Pourquoi ce n’est pas trivial
Le pricing n’est pas un artefact. C’est une procédure, la définition de contexte qu’elle lit, les decision tables qu’elle appelle, les barèmes d’ajustement qu’elle applique et les PricebookEntry en dessous. Déplacez-en un sous-ensemble et la procédure s’exécute et ne rend rien — ce qui ressemble à un bug de pricing et est un bug de déploiement.
L’architecture recommandée
Traiter la configuration de pricing comme une seule unité de déploiement avec un inventaire explicite, et déployer dans l’ordre des dépendances : le contexte, puis les tables et les barèmes, puis la procédure, puis les prix.
Composants Salesforce
Sélectionnez-en un pour ouvrir son détail.
Le flux
Scroll the diagram sideways
La règle qui garde un catalogue maintenable : une decision table seulement s’il y a une condition ou un palier. Un prix fixe vit sur le PricebookEntry. Les decision tables ajoutées par réflexe sont ce qui remplit une procédure jusqu’à son plafond.
Et la procédure qui s’exécute est la version compilée _Auto, pas la source que vous éditez.
Mise en œuvre
- Inventorier ce que la procédure référence, y compris les identifiants en dur dans ses steps.
- Déployer dans l’ordre des dépendances et réactiver la procédure à la fin — la déployer ou l’éditer la laisse inactive.
- Vérifier en repriçant un vrai devis et en lisant les totaux de ligne, pas en inspectant la configuration.
Attention
- Les steps de procédure peuvent porter des identifiants d’enregistrement en dur. Les identifiants ne survivent pas à un changement d’org : une procédure qui en référence un cesse silencieusement d’appliquer ce qu’il désignait.
- La procédure compilée
_Autoest celle qui s’exécute ; vérifier la source ne prouve rien. - Salesforce publie des recommandations de déploiement spécifiques à ces objets — à lire avant la première tentative plutôt qu’après le premier échec.
Alternatives
Reconstruire à la main dans l’org cible est plus lent mais parfois plus sûr pour une première mise en production, parce que ça force l’inventaire. Ça ne passe pas à l’échelle sur des livraisons répétées.