Comment corriger DEPENDENCY_EXISTS dans les déploiements Salesforce

Salesforce refuse de supprimer un champ, un objet ou une valeur de picklist parce qu'un autre composant y fait encore référence.

Se produit lors de : la suppression de métadonnées, via destructiveChanges.xml ou Setup

Ce que cela signifie

DEPENDENCY_EXISTS bloque la suppression de métadonnées, un champ personnalisé, un objet, un record type ou une valeur de picklist, parce qu'autre chose dans l'org y fait toujours référence : une formule, une validation rule, un flow, un report, ou un page layout. Salesforce protège l'intégrité des données en refusant de retirer un composant tant que des dépendants en ont besoin.

Cela ne se déclenche que lorsque la métadonnée existe déjà dans l'org cible et que quelque chose la supprime, que ce soit via Setup, un déploiement destructiveChanges.xml, ou la Tooling API ; cela n'apparaît jamais lors d'un simple déploiement additif de nouvelles métadonnées.

Diagnostic

Causes courantes

Un champ formule ou une validation rule y fait référence

Un champ formule, une validation rule ou une workflow rule lit le champ ou l'objet en cours de suppression, et Salesforce refuse de rompre cette référence.

Des reports ou list views l'utilisent encore

Un report enregistré, un report type ou une list view filtre ou affiche le champ, ce qui le maintient "en cours d'utilisation" même si plus personne ne l'exécute.

Un Flow ou du code Apex fait toujours référence au champ

Un Flow, un processus Process Builder ou une classe Apex interroge ou assigne le champ, ce qui fait que la plateforme le traite comme une dépendance active.

La solution

Trouvez chaque dépendant avec la vérification des dépendances de Salesforce
Utilisez l'outil "Where is this used?" dans Setup sur le champ ou l'objet pour lister chaque formule, flow, report et layout qui y fait référence.
Supprimez ou mettez à jour chaque dépendance en premier
Modifiez ou supprimez la formule, le flow, la validation rule ou le report qui fait référence, afin qu'il ne pointe plus vers le composant.

Supprimez le composant dans une étape distincte

Une fois qu'il ne reste plus de dépendants, supprimez le champ ou l'objet seul, après que le nettoyage des dépendances a été appliqué dans l'org cible.

<!-- destructiveChangesPost.xml, deployed after the dependency cleanup lands -->
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <members>Account.Legacy_Score__c</members>
    <name>CustomField</name>
  </types>
  <version>62.0</version>
</Package>

En pratique

Comment Serpent évite cela

Serpent exécute une vérification préalable des dépendances avant qu'une suppression n'atteigne une org partagée, de sorte qu'un champ toujours référencé apparaisse comme une tâche bloquée plutôt que comme un déploiement en production en échec. Voir la bibliothèque des erreurs de déploiement Salesforce.

Constructeur de pipelines CI/CD no-code dans Serpent

Prévention

Effectuez la vérification des dépendances avant de planifier tout retrait d'un champ ou d'un objet

Faites de "Where is this used?" une étape obligatoire de la checklist de dépréciation, pas une étape de débogage à laquelle vous recourez après le premier échec.

Retirez les références avant de planifier la suppression

Déployez le nettoyage des formules, flows et reports comme son propre déploiement, puis planifiez la suppression destructive comme une release séparée et ultérieure.

Utilisez le modèle de déploiement destructif en deux phases de la Metadata API

Déployez destructiveChangesPre.xml pour le pré-nettoyage et destructiveChangesPost.xml pour le retrait final, conformément au séquencement de suppression recommandé par Salesforce lui-même.

Erreurs associées

DELETE_FAILEDL'équivalent au niveau des enregistrements de données pour cette erreur : un enregistrement au lieu d'un composant de métadonnées.ENTITY_IS_DELETEDL'échec qui se produit de l'autre côté, lorsqu'une suppression s'exécute avant que ses dépendants ne soient nettoyés.CANNOT_CASCADE_PRODUCT_ACTIVEUne version spécifique à la tarification du même schéma où une dépendance bloque une suppression.

Questions fréquentes

DEPENDENCY_EXISTS, les réponses

Pourquoi DEPENDENCY_EXISTS n'apparaît-il que lorsque je déploie vers une sandbox ou la production ?

Parce que les sandbox et la production contiennent souvent des reports, flows ou layouts qui n'existent pas dans une scratch org ou une sandbox de développement, la dépendance reste invisible jusqu'à ce que vous déployiez là où ces dépendants existent réellement.

L'outil "Where is this used?" détecte-t-il tous les types de dépendances ?

Il détecte la plupart des dépendances déclaratives, formules, flows, layouts, reports, mais peut manquer des références dynamiques à l'intérieur d'Apex, comme un nom de champ construit à partir d'une chaîne dans SOQL, donc recherchez aussi dans votre code avant de supprimer.

Puis-je supprimer un champ uniquement référencé dans une version inactive d'un Flow ?

Non. Salesforce vérifie toutes les versions d'un Flow, pas seulement la version active, donc une version inactive qui référence le champ bloque quand même la suppression.

Commencez gratuitement. Sans carte bancaire, sans installation, sans engagement.

Configuration en moins de 15 minutes. Aucune embauche DevOps nécessaire.

Commencer gratuitement Réserver une démo