ENTITY_IS_DELETED in Salesforce-deployments oplossen

De metadata of het record waarnaar de deployment verwijst is verwijderd, of bevindt zich in de Recycle Bin, in de doel-org.

Komt voor bij: runtime DML en metadata-deploys die verwijzen naar een inmiddels verwijderde component

Wat het betekent

ENTITY_IS_DELETED betekent dat de component of het record die je deployment verwacht te vinden al is verwijderd in de doel-org. Dit gebeurt wanneer eerder opgehaalde metadata inmiddels verouderd is, of wanneer een destructieve wijziging en een afhankelijke deployment in de verkeerde volgorde tegen elkaar draaien.

Het kan op beide niveaus optreden: een Apex-query of DML-statement dat een soft-verwijderd record raakt dat nog in de Recycle Bin staat, of een Metadata API-deploy die verwijst naar een component die een eerdere destructiveChanges.xml al uit de doel-org heeft verwijderd.

Diagnose

Veelvoorkomende oorzaken

Verouderde lokale metadata

Een veld, object of record type is rechtstreeks in de doel-org verwijderd na de laatste retrieve, waardoor lokale metadata er nog naar verwijst.

Testdata midden in de transactie verwijderd

Een Apex-test of trigger verwijdert een record dat een latere stap in dezelfde transactie probeert te bevragen of bij te werken.

Destructieve wijzigingen in de verkeerde volgorde uitgevoerd

Een destructiveChanges.xml-verwijdering wordt uitgevoerd vóór metadata die nog afhankelijk is van de te verwijderen component.

De oplossing

Synchroniseer opnieuw vóór het deployen
Haal actuele metadata op uit de doel-org om te bevestigen dat de component daar echt nog bestaat.
```
sf project retrieve start --target-org myOrgAlias --metadata CustomField:Account.Legacy_Score__c
```
Verwijder of herstel de verwijzing
Verwijder de verouderde verwijzing uit je metadata, of herstel de component vanuit de Recycle Bin als deze nog zou moeten bestaan.
Sequentieer destructieve wijzigingen correct
Deploy afhankelijke metadatawijzigingen eerst, en voer destructieve verwijderingen daarna uit, volgens het tweestaps destructieve deploypatroon van Salesforce.

In de praktijk

Hoe Serpent dit voorkomt

Serpent AI haalt vóór elke taak de live orgstatus op en markeert een verwijderde component als een diffconflict om op te lossen, in plaats van deze midden in de deploy te laten mislukken. Zie de bibliotheek met Salesforce-deploymentfouten.

Metadata en data in één deploymentflow in Serpent

Preventie

Haal op vóór elke retrieve-and-modify workflow, ga nooit uit van actualiteit

Behandel lokaal gecachte metadata als wegwerpbaar; haal verse status op uit de doel-org vlak voordat je er een deployment tegen bouwt.

Bevraag records opnieuw na elke delete binnen dezelfde transactie

Ga er nooit van uit dat een record dat eerder in een Apex-methode is bevraagd nog bestaat nadat later in dezelfde transactie een delete-statement is uitgevoerd; bevraag opnieuw of herstructureer de logica.

Standaardiseer op destructiveChangesPre/Post.xml voor elke verwijdering

Splits verwijderingen altijd op met behulp van Salesforce's gedocumenteerde pre- en post-destructieve wijzigingsbestanden in plaats van ad hoc verwijderingsvolgorde.

Gerelateerde fouten

DEPENDENCY_EXISTSDe blokkade die voorkomt dat deze fout überhaupt optreedt, wanneer Salesforce de afhankelijkheid al vóór de verwijdering opmerkt.DELETE_FAILEDDe versie op recordniveau van een geblokkeerde verwijdering, in plaats van stilzwijgend slagen in de verkeerde volgorde.INVALID_CROSS_REFERENCE_KEYEen verwante fout wanneer een verwijzing wijst naar iets dat helemaal nooit in de doel-org heeft bestaan.CANNOT_UPDATE_CONVERTED_LEADNog een op status gebaseerde blokkade: het record bestaat nog, maar conversie heeft het alleen-lezen gemaakt.

Veelgestelde vragen

ENTITY_IS_DELETED, beantwoord

Kan ik een component herstellen die per ongeluk is verwijderd?

Als deze recent is verwijderd, controleer dan eerst de Recycle Bin van de org. Zowel metadatacomponenten als records blijven daar gedurende een beperkte tijd herstelbaar.

Hoe lang blijft een verwijderd record of metadatacomponent in de Recycle Bin?

Records blijven doorgaans 15 dagen herstelbaar voordat ze permanent worden verwijderd; sommige metadatatypen hebben hun eigen bewaartermijnen, dus controleer Setup voor het specifieke componenttype.

Voorkomt het bevragen van een Recycle Bin-record met ALL ROWS deze fout?

Voor SOQL-queries kan dat. Door ALL ROWS toe te voegen kan een query soft-verwijderde records zien, maar elke DML-update of -delete daarop mislukt nog steeds totdat het record is hersteld.

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

Binnen 15 minuten ingesteld. Geen DevOps-aanwerving nodig.

Start gratis Boek een demo