Indexer les renouvellements sans code : le flow Renew qu’on aurait dû faire dès le début

Revenue Cloud sait porter un taux d’augmentation sur un actif, et le renouvellement natif le recopie sur la ligne de devis. Terrain Il reste à poser le bon taux, au bon moment, sur les bons produits. C’est tout le sujet.

Première version : un bouton à part, et une mauvaise idée

On a d’abord créé un bouton « Préparer le renouvellement » sur le contrat : il lisait l’indice, posait le taux sur les actifs, et l’utilisateur lançait ensuite le renouvellement natif.

L’équipe ne s’en est jamais servie. Les utilisateurs cliquent sur Renouveler, pas sur un bouton préparatoire. Le bon endroit pour une automatisation, c’est le bouton qu’ils utilisent déjà — pas un bouton de plus à côté. Recommandé

Partir du flow natif des boutons d’actifs

Les boutons Amend, Renew, Cancel et Swap des actifs ne sont pas codés en dur. Ils lancent un flow, choisi dans les réglages Revenue Cloud. Par défaut, c’est un flow managé : non modifiable, non récupérable. Terrain

On la copie depuis le modèle fourni par Salesforce, puis on l’enrichit. Il faut en connaître le prix avant de se lancer : on devient propriétaire du flow, et on ne reçoit plus les évolutions que Salesforce apporte au flow standard. À relire à chaque release. Recommandé, en connaissance de cause.

Ce que le client détient, et les boutons qui le font évoluerCompte › Managed Assets

123

Ce que fait le flow

Sur l’action Renouveler, après l’écran de durée :

1. Il lit l’indice du compte. Le compte porte une référence vers un indice, et les valeurs publiées sont stockées par mois.
2. Il prend la dernière valeur publiée et calcule le taux. L’indice étant stocké en coefficient — 1,0158 — le taux vaut (coefficient − 1) × 100, soit 1,58 %.
3. Il affiche un deuxième écran. Avec le taux et une question : « Appliquer cette indexation au renouvellement ? ». La réponse Oui est cochée par défaut : on veut que l’indexation soit la règle et que l’exception demande un geste. Recommandé
4. Il pose le taux sur les actifs des seuls produits indexés. Une case sur le produit dit si son renouvellement suit l’indice ou le prix catalogue.
5. Il lance le renouvellement natif. Qui recopie le taux sur les lignes du devis.

Le commercial peut toujours corriger le taux à la main sur le devis, pour appliquer un taux négocié par exemple. L’automatisation propose, elle ne verrouille pas.

Le flow qui faisait renouveler pour douze ans

Le renouvellement natif refuse tout actif sans durée de renouvellement : « All assets in a request must have values for RenewalTermUnit and RenewalTerm ». Ces deux champs n’existent que sur l’actif, et rien ne les remplit. Terrain

On a donc ajouté un flow before-save sur l’actif, qui déduit la durée des dates de cycle de vie. Première version : la durée en mois, soit 12 mois pour un abonnement annuel.

Le renouvellement est sorti sur douze ans. Le moteur lit la durée de renouvellement dans l’unité du selling model de la ligne : 12 sur un modèle annuel, c’est douze années. Terrain

Correctif : une durée en années pleines est posée en années, sinon en mois. Et une passe de correction sur les actifs déjà remplis à tort — sinon le premier renouvellement de l’année part sur une décennie.

Ce que le flow ne peut pas faire seul

Le taux était bien sur la ligne. Le prix renouvelé, lui, ne bougeait pas. Il sortait même au prix catalogue, sans remise de bundle, avec les composants inclus facturés.

Ce n’est pas le flow. C’est la pricing procedure, qui écartait les lignes de renouvellement de plusieurs groupes et réécrivait leur prix en fin de calcul. C’est l’objet de Renouvellement au prix catalogue. Sans cette correction, le flow pose un taux que personne n’applique.

C’est la leçon la plus utile du chantier : une automatisation de renouvellement se teste sur un montant, pas sur un champ. Vérifier que le taux est bien posé ne prouve rien.

Les petits pièges du flow copié

• Un champ cassé dans la copie. Un Get Records stockait un champ de produit lié, ce qu’un Get Records ne sait pas faire. Le champ est devenu une référence introuvable, et la version ne pouvait plus s’activer. On stocke l’identifiant du produit, et la décision lit le champ à travers lui. Terrain
• La version enregistrée n’est pas forcément l’active. Une sauvegarde en erreur crée une version brouillon invalide plus récente. Un retrieve récupère la dernière version, pas l’active, et c’est elle qui partirait en production. Terrain
• Un flow déployé en production arrive en brouillon. Il faut l’activer à la main, et vérifier que les réglages Revenue Cloud pointent bien sur la copie — pas sur le flow managé.

Ce qu’un actif raconte dans la duréeActif › Dashboard

123

Ce que ça coûte

• Un flow à maintenir. À la place du flow standard, à relire à chaque release.
• Un modèle de données d’indice : L’indice par compte, et ses valeurs publiées par mois.
• Une décision métier : Dernière valeur publiée, ou valeur du mois anniversaire ? On a pris la dernière publiée, modifiable à la main. Recommandé

Composants Salesforce

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

Sur quoi ça repose

• Le renouvellement natif recopie le taux d’augmentation de l’actif vers la ligne de devis : observé terrain, pas trouvé dans la documentation.
• La lecture de la durée de renouvellement dans l’unité du selling model est observée sur des modèles annuels. À vérifier pour d’autres périodicités.
• Le choix du flow dans les réglages Revenue Cloud n’était pas exposé en métadonnée sur notre org : il se règle à la main dans chaque environnement, et ça s’oublie.
• Constaté sur une org en Summer ’26 / Winter ’27.