Trying to uninstall a package - but one lonely record refers to RecordType in that package, and so long as that is the case, I can't remove the package. But that record is deleted, and not available in Recycle Bin.

So this query actually returns the record:

[Select Id, IsDeleted, RecordTypeId, LastModifiedDate from Contact where Id = 'XXX' all rows];

But when I try and undelete the record, it won't let me, and I can't update it...

Do I have any options other than wait for SFDC to finally purge it? It was deleted on Oct 30th, so how much longer will I need to wait?

  • Did you check your org's recycle bin in addition to your own?
    – Mike Chale
    Commented Nov 13, 2013 at 21:38

4 Answers 4


Deleting a parent record can also delete its children records. For example, deleting accounts also deletes contacts. If you search the for the child record in the recycle bin, it won't appear in the list. You can query for it, but you'll get an error "Entity is not in the recycle bin" if you try to undelete it. Restoring the parent record also restores the children records. Purging the parent also irrevocably deletes the children records; this is what salesforce is expecting you to do before you can uninstall the package. Edit: It occurred to me that it's important to note an important aspect here: If you can query it in Apex Code or the Data Loader, it's either active or soft-deleted. Hard deleted records only appear in the replication API, and only for 30 days. Normal Apex Code can't query hard-deleted data, so the fact that you can still see it means it is still only soft-deleted.


There is a process that salesforce runs in the background every certain time which performs a hard delete of the records that have been deleted. You can experience this issue when the record has been deleted from the recycle bin but that process hasn't run. Open a case with support and ask them to do a hard delete on your recycle bin.

  • Or they could just empty the organization recycle bin. No need to involve support unless the "Organization Recycle Bin" is empty and the error persists. Note that cascade-deletes are not indicated in the recycle bin. See answer I've provided.
    – sfdcfox
    Commented Nov 14, 2013 at 4:00
  • Yeah, I was assuming that the recycle bin was empty but I just noticed that the OP did not indicate that.
    – PepeFloyd
    Commented Nov 14, 2013 at 5:00
  • Recycle Bin is empty...I followed the advice about parent/child - the parent account record is also still available via an ALL ROWS query using Dev Console, but trying to undelete that throws same error - UNDELETE_FAILED, Entity is not in the recycle bin. I'll give it another 24 hours, then raise a case... Commented Nov 14, 2013 at 5:04
  • This is the correct answer. Recycle Bin seemingly can't show records, for example, that got created through data import with their created date being very old (it's 2023 now and some of the records I am seeing are 2012, 2017, etc), and then subsequently deleted.. similar to how activities get isArchived=true help.salesforce.com/s/articleView?id=000387294&type=1
    – CRT
    Commented Nov 16, 2023 at 15:00

Normally, records sit in the (first) Recycle Bin for 15 days, before moving to a secondary recycle bin accessible only to administrators. As an administrator, you should be able to purge the record before the time period is up (if you have Modify All Data.)

  1. Go to the Recycle Bin
  2. Click Empty your Recycle Bin or Empty your organization's Recycle Bin.

You can find more at Using the Recycle Bin.

Note: The record may have left a personal Recycle Bin and exist inside the organization's Recycle Bin. Make sure to check there, too.

  • But I don't think it is any recycle bin - when I execute an Undelete Statement on the record returned, I get this error: System.DmlException: Undelete failed. First exception on row 0 with id 003F0000016jZJLIA2; first error: UNDELETE_FAILED, Entity is not in the recycle bin Commented Nov 13, 2013 at 21:44
  • Do you have Modify All Data on your profile?
    – Mike Chale
    Commented Nov 13, 2013 at 21:59
  • I do - not sure I could access this data otherwise. I think there is a gap between when it leaves the recycle bin and is actually considered deleted by SFDC - which isn't normally an issue, but packages seem to look at the twilight world data rather than the recycle bin as their reference for dependencies... Commented Nov 14, 2013 at 0:46
  • 2
    The recycle bin doesn't work like stated here. There's only one recycle bin. "My Recycle Bin" versus "Organization's Recycle Bin" only refers to finding items you've deleted versus finding items other people have deleted. Any item in any "My Recycle Bin" will also exist in the "Organization Recycle Bin." Records have only 15 days before they are hard deleted, period. There is a period between the time they are hard deleted and database deleted, but they are never considered in actions that would otherwise block because of the record.
    – sfdcfox
    Commented Nov 14, 2013 at 3:58
  • 1
    In the event of a Recycle Bin overflow, the automatic hard delete sweeper that runs approximately every 24 hours or so (I don't have a time on this, but I know it's infrequent) will hard delete the oldest deleted records down to the limit allowed for the recycle bin. This has the same effect as using the "Empty Recycle Bin" functions-- the records are permanently lost. Once hard deleted by any means, they do not go to limbo-- they go directly to bit heaven, where all the good bits go when they are deleted. ALL ROWS won't find records deleted by the sweeper or by Empty Recycle Bin.
    – sfdcfox
    Commented Nov 14, 2013 at 15:58

We are having a similar/related problem right now. Even after you purge (empty org recycle bin) the deleted records are still returned with a queryAll (soap or REST) for up to 24 hours. In our case it has been 36 hours and it still returns all the records purged from the recycle bin. Extremely frustrating and not well documented.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .