How to fix ENTITY_IS_DELETED in Salesforce deployments

The metadata or record the deployment references has been deleted, or sits in the Recycle Bin, in the target org.

Surfaces during: runtime DML and metadata deploys that reference a since-deleted component

What it means

ENTITY_IS_DELETED means the component or record your deployment expects to find has already been removed in the target org. This happens when metadata retrieved earlier is now stale, or when a destructive change and a dependent deployment run in the wrong order against each other.

It can fire at either layer: an Apex query or DML statement hitting a soft-deleted record still in the Recycle Bin, or a Metadata API deploy referencing a component that a prior destructiveChanges.xml already removed from the target org.

Diagnosis

Common causes

Stale local metadata

A field, object, or record type was deleted directly in the target org after the last retrieve, so local metadata still references it.

Test data deleted mid-transaction

An Apex test or trigger deletes a record that a later step in the same transaction tries to query or update.

Destructive changes run in the wrong order

A destructiveChanges.xml deletion runs before metadata that still depends on the component being deleted.

The fix

Re-sync before deploying
Retrieve current metadata from the target org to confirm the component genuinely still exists there.
```
sf project retrieve start --target-org myOrgAlias --metadata CustomField:Account.Legacy_Score__c
```
Remove or restore the reference
Delete the stale reference from your metadata, or restore the component from the Recycle Bin if it should still exist.
Sequence destructive changes correctly
Deploy dependent metadata changes first, then run destructive deletions afterward, following Salesforce's two-step destructive deploy pattern.

In practice

How Serpent prevents this

Serpent AI pulls live org state before every task and flags a deleted component as a diff conflict to resolve, instead of letting it fail mid-deploy. See the Salesforce deployment error library.

Metadata and data in one deployment flow in Serpent

Prevention

Retrieve before every retrieve-and-modify workflow, never assume freshness

Treat locally cached metadata as disposable; pull fresh state from the target org immediately before building a deployment against it.

Requery records after any delete within the same transaction

Never assume a record queried earlier in an Apex method still exists after a delete statement runs later in the same transaction; requery or restructure the logic.

Standardize on destructiveChangesPre/Post.xml for every deletion

Always split deletions using Salesforce's documented pre and post destructive change files instead of ad hoc deletion ordering.

Common questions

ENTITY_IS_DELETED, answered

Can I recover a component that was deleted by mistake?

If it was deleted recently, check the org's Recycle Bin first. Metadata components and records both stay recoverable there for a limited time.

How long does a deleted record or metadata component stay in the Recycle Bin?

Records typically stay recoverable for 15 days before being permanently purged; some metadata types have their own retention windows, so check Setup for the specific component type.

Does querying a Recycle Bin record with ALL ROWS avoid this error?

It can, for SOQL queries. Adding ALL ROWS lets a query see soft-deleted records, but any DML update or delete against them still fails until the record is undeleted.

Start free. No credit card, no install, no commitment.

Set up in under 15 minutes. No DevOps hire needed.

Start free Book a demo