Ah les champs de dépendances… C’est beau. On assure une donnée de qualité et cela permet aux utilisateurs d’avoir une liste de choix beaucoup moins longue.
C’est ce que m’a demandé mon client : la possibilité d’avoir les différentes raisons de perte d’une opportunité filtrées par l’étape de l’opportunité.
Nouvelle fonctionnalité
Armée de mon nouvel outil SFDX, je prépare cette nouvelle fonctionnalité.
J’ajoute les valeurs de liste de sélection sur “Closing Stage”, je crée la liste de sélection “Lost Reason” et ses valeurs puis je définis la relation entre ces deux champs.
Je récupère mes fichiers en local et les déploie en environnement de test. Cette fonctionnalité est validée. Cela part en production.
Mon sprint s’achève, le suivant commence. De nouvelles fonctionnalités apparaissent.
Jusqu’alors nous avions défini des opportunités concernant la vente de bien immobilier. Dans ce nouveau sprint, nous nous intéressons aux opportunités concernant l’achat de bien. Il faut donc mettre à jour la relation de dépendance avec les nouveaux statuts de l’opportunité et les nouvelles raisons de perte.
Les champs “Closing Stage” et “Lost Reason” ont déjà été mis à jour, récupérés en local et déployés en production.
Il ne me reste donc plus qu’à compléter la matrice de dépendance de ces champs.
J’effectue d’autres modifications puis je pull le tout et le déploie en environnement de test.
Un bug remonte
Quelques temps après, les tests ont lieu et ce qui devait arriver arriva : un bug remonte.
La relation de dépendance correspond à l’ancienne et non à celle prenant en compte les opportunités d’achat de biens immobilier.
Je me demande ce que j’ai mal fait.
Je vais sur la matrice de dépendance de champ, je fais une modification, je sauvegarde, je récupère mes fichiers. Rien.
Impossible de récupérer mes modifications.
Je me demande alors où sont stockées ces informations de dépendance de champs. J’explore mes fichiers SFDX en quête d’un fichier de dépendance. Chou blanc. Finalement je trouve ce que je cherche au cœur du fichier de définition du champ dépendant : “Lost Reason”.
Je retourne donc sur ma Scratch Org, fais un Edit/Save sur mon champ “Lost Reason” puis je pull.
Ma nouvelle définition de champ dépendant est bien là.
Très bien, j’ai identifié mon problème mais comment je corrige la dépendance de champ en environnement de test ?
Cette nouvelle définition avait été faite sur une Scratch Org disparue depuis. Il m’était donc impossible de me reconnecter dessus, faire la manipulation puis de pull le fichier.
Une seule solution restante : recommencer.
En l’occurrence 45 choix répartis sur 19 étapes soit une matrice de 855 cases…
C’est pourquoi aujourd’hui je vous partage mon expérience sur les champs dépendants avec SFDX en espérant qu’elle vous sera utile.
Bon à savoir
La dépendance de champ est stockée dans le fichier XML du champ dépendant. Il suffit donc d’effectuer un Edit/Save sur le champ dépendant avant de pull.
J’ai aussi remonté ce comportement à Salesforce sur la Trailerblazer Community qui a été pris en compte par Salesforce et tracé en bug. Je vous tiendrai au courant lorsqu’il sera corrigé.
En attendant, je continuerai à vous faire part de mes problèmes liés à SFDX et leurs solutions de mon point de vue d’AppBuilder.
