Pricing·Référence·6 min·Mis à jour le 05/10/2026
Cas d’usage · Pricing
Frais de setup par paliers et adders à l’unité
Un frais de setup qui change de palier à un seuil, plus des adders qui se calculent sur un comptage — sans remplir la pricing procedure.
Le besoin métier
Un frais de setup à un prix sous un seuil d’effectif et à un autre au-dessus, plus des adders à l’unité, pilotés par une quantité qui n’est pas le nombre de postes.
Pourquoi ce n’est pas trivial
Deux quantités différentes pilotent le prix et on les confond facilement. Et chaque seuil exprimé en decision table consomme une capacité de procédure qui est finie.
L’architecture recommandée
Une decision table pour le seuil — c’est une vraie condition — et les adders fixes sur le PricebookEntry. Pilotez l’élément qui se calcule par le champ qui porte réellement le comptage, pas par celui dont le nom sonne juste.
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
Nommez explicitement la quantité pilote sur le produit et écrivez quelle quantité pilote quel élément. C’est le détail qu’on redérive péniblement un an plus tard.
Attention
- Une decision table pour un prix sans condition est du gaspillage pur contre le plafond d’éléments. Les prix fixes vont sur le PricebookEntry.
- Éditer la procédure la désactive.
Alternatives
Exprimer les seuils en produits distincts supprime la decision table et multiplie le catalogue. Raisonnable à deux paliers, ingérable à cinq.