DEPENDENCY_EXISTS in Salesforce-deployments oplossen

Salesforce verwijdert een veld, object of picklistwaarde niet omdat een ander component er nog naar verwijst.

Komt voor bij: metadata verwijderen, via destructiveChanges.xml of Setup

Wat het betekent

DEPENDENCY_EXISTS blokkeert het verwijderen van metadata, een custom field, object, record type of picklistwaarde, omdat iets anders in de org er nog naar verwijst: een formule, een validation rule, een flow, een report, of een page layout. Salesforce beschermt de data-integriteit door te weigeren een component te verwijderen terwijl er nog afhankelijkheden van bestaan.

Dit treedt alleen op wanneer de metadata al in de doel-org bestaat en er iets wordt verwijderd, of dat nu via Setup, een destructiveChanges.xml-deployment, of de Tooling API is; het verschijnt nooit bij een gewone additieve deploy van nieuwe metadata.

Diagnose

Veelvoorkomende oorzaken

Formulaveld of validation rule verwijst ernaar

Een formulaveld, validation rule of workflow rule leest het veld of object dat wordt verwijderd, en Salesforce weigert die referentie te verbreken.

Reports of list views gebruiken het nog

Een opgeslagen report, report type of list view filtert of toont het veld, waardoor het "in gebruik" blijft, zelfs als niemand het nog uitvoert.

Flow of Apex verwijst nog naar het veld

Een Flow, Process Builder-proces of Apex class bevraagt of wijst het veld toe, waardoor het platform het als een actieve afhankelijkheid behandelt.

De oplossing

Vind elke afhankelijkheid met Salesforces dependency check
Gebruik de tool "Where is this used?" in Setup op het veld of object om elke formule, flow, report en layout die ernaar verwijst op te sommen.
Verwijder of werk elke afhankelijkheid eerst bij
Bewerk of verwijder de verwijzende formule, flow, validation rule of report zodat deze niet langer naar het component wijst.

Verwijder het component in een aparte stap

Zodra er geen afhankelijkheden meer over zijn, verwijder je het veld of object op zichzelf, nadat de dependency-opschoning in de doel-org is doorgevoerd.

<!-- 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>

In de praktijk

Hoe Serpent dit voorkomt

Serpent voert een preflight dependency check uit voordat een verwijdering een gedeelde org bereikt, zodat een veld dat nog wordt gerefereerd naar voren komt als een geblokkeerde taak in plaats van een mislukte productie-deploy. Zie de Salesforce-deploymentfoutenbibliotheek.

No-code CI/CD-pipelinebuilder in Serpent

Preventie

Voer de dependency check uit voordat je een veld of object plant voor uitfasering

Maak "Where is this used?" een verplichte stap in de deprecation-checklist, niet een debugstap waar je pas naar grijpt na de eerste mislukking.

Fase referenties uit voordat je de verwijdering plant

Voer de opschoning van formules, flows en reports als eigen deployment door, en plan de destructieve verwijdering vervolgens als een aparte, latere release.

Gebruik het tweefasige destructive-deploypatroon van de Metadata API

Deploy destructiveChangesPre.xml voor de voorbereidende opschoning en destructiveChangesPost.xml voor de definitieve verwijdering, conform Salesforces eigen aanbevolen volgorde voor verwijderingen.

Gerelateerde fouten

DELETE_FAILEDHet data-record-equivalent van deze fout: een record in plaats van een metadatacomponent.ENTITY_IS_DELETEDDe fout die aan de andere kant optreedt, wanneer een verwijdering plaatsvindt voordat de afhankelijkheden ervan zijn opgeschoond.CANNOT_CASCADE_PRODUCT_ACTIVEEen prijsspecifieke variant van hetzelfde patroon waarbij een afhankelijkheid een verwijdering blokkeert.

Veelgestelde vragen

DEPENDENCY_EXISTS, beantwoord

Waarom verschijnt DEPENDENCY_EXISTS pas als ik naar een sandbox of productie deploy?

Omdat sandboxes en productie vaak reports, flows of layouts bevatten die niet in een scratch org of dev sandbox bestaan, is de afhankelijkheid onzichtbaar totdat je deployt naar een omgeving waar die afhankelijkheden daadwerkelijk bestaan.

Vangt de tool "Where is this used?" elk type afhankelijkheid?

Deze vangt de meeste declaratieve afhankelijkheden, formules, flows, layouts, reports, maar kan dynamische referenties binnen Apex missen, zoals een veldnaam die is opgebouwd uit een string in SOQL, dus doorzoek ook je codebase voordat je verwijdert.

Kan ik een veld verwijderen dat alleen wordt gerefereerd in een inactieve Flow-versie?

Nee. Salesforce controleert alle versies van een Flow, niet alleen de actieve, dus een inactieve versie die het veld refereert blokkeert de verwijdering nog steeds.

Start gratis. Geen creditcard, geen installatie, geen verplichting.

Binnen 15 minuten ingesteld. Geen DevOps-aanwerving nodig.

Start gratis Boek een demo