quote → cash
FR/EN Contact

Migration·Référence·9 min·Mis à jour le 05/10/2026

Cas d’usage · Produit

Venir de Salesforce CPQ

Ce qui se transfère, ce qui ne se transfère pas, et la distinction qui rend inapplicable l’essentiel de la littérature CPQ.

Salesforce docs documenté par SalesforceTerrain constaté sur une vraie orgRecommandé ce que nous recommandonsÀ vérifier non vérifié

Le besoin métier

Une org sous Salesforce CPQ doit passer sur la plateforme native Revenue Cloud.

Pourquoi ce n’est pas trivial

Ce sont des produits différents, pas deux versions d’un même. Salesforce CPQ est un package managé acquis, avec son namespace SBQQ__, ses price rules et ses product rules. La plateforme native n’a pas de namespace et price par pricing procedures, expression sets et decision tables. Si une org porte le namespace CPQ, presque rien de ce qui est écrit sur la plateforme native ne s’y applique — et réciproquement.

L’architecture recommandée

Traitez-la comme une réimplémentation de la logique commerciale, pas comme une migration de données. Le catalogue et les clients migrent ; les règles sont réécrites, parce que les deux moteurs de règles n’ont aucun concept commun.

Composants Salesforce

Sélectionnez-en un pour ouvrir son détail.

Le flux

Architecture produit et catalogue deux axes, un produit
CATALOGUE DÉFINITION VENTE browse shape required ProductCatalog le contenant ProductCategory le rayon Classification ce que c’est AttributeDefinition ce qu’il porte Product2 le produit SellingModel comment il se vend RelatedComponent le bundle PricebookEntry le prix de liste

Scroll the diagram sideways

Les attributs sont portés par la classification, pas par le produit. La catégorie n’est que l’endroit où le commercial navigue. Les modéliser comme une seule idée fonctionne jusqu’au premier produit qui doit apparaître sur deux rayons, ou aux deux produits de même type qui ont besoin d’attributs différents.

Le flux

Architecture du pricing contexte → procédure → prix
ENTRÉE DÉCIDER EXÉCUTER SORTIE ContextDefinition ce que le pricing voit DecisionTable si conditionnel Barème d’ajustement paliers et franchises PricebookEntry si sans condition Pricing procedure ExpressionSet Prix net sur la ligne

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

  1. Inventorier les règles commerciales en termes métier, indépendamment de la façon dont CPQ les exprimait.
  2. Les reconstruire en procédures et decision tables, en appliquant la règle « une table seulement pour une condition ou un palier ».
  3. Redériver la structure du catalogue sur les axes classification / catégorie / bundle plutôt que de transposer celle de CPQ.

Attention

  • Vérifiez le namespace avant de faire confiance au moindre article, celui-ci compris. C’est le moyen le plus rapide de savoir de quel produit on parle.
  • La plateforme a été renommée plusieurs fois. La documentation de Salesforce dit désormais que Revenue Cloud s’appelle Revenue Management, et des documents plus anciens emploient encore d’autres noms pour la même chose.

Alternatives

Rester sur CPQ reste viable quand le modèle commercial est stable et les règles profondes. Le déplacement vaut le coup pour le cycle de vie natif et la facturation, pas pour la seule expérience de devis.

Ressources Salesforce

Guide