function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
John SaundersJohn Saunders 

AccountShare record with Deleted AccountId?

In testing an application, I found many AccountShare records where the AccountId field refers to deleted Account records. I thought that deleting an Account should have cascaded down and deleted the AccountShare records?

Is this normal, and is there some way I could programatically determine that the AccountId was bogus? I could use getDeleted to get the Id's of the last "n" days of Accounts, but would this AccountShare record still be there after the deleted Account ages out of the recycle bin (or the recycle bin is emptied)?

John Saunders


John SaundersJohn Saunders

It's been a while now since I posted the original. Does nobody have a clue about this?

John Saunders



Hi John,

I believe this is to support the recycle bin.  When the bin is cleared or the items in it expire, the deleted account id will go away.

John SaundersJohn Saunders


Thanks for answering. Should I have opened a support case for this one?

Our experiments were unable to reproduce this on our own data. When we created an Account and AccountShare, deleting the Account also deleted the AccountShare. But with the customer's data, 357 of the AccountShare records show this behavior.

Even if the Account were meant to be in the recycle bin, surely the corresponding child records should have been in the recycle bin as well?

It's ok for "delete" to mean either "really delete" or "put in the recycle bin". But in either case, "cascade delete" should correspond to "delete".

Also, how would I detect this problem? In particular, given that I notice a problem with a particular AccountShare record, is there a way to be sure that it references a deleted account and not simply one which never existed? For instance, will I always be able to use getDeleted to find the list of deleted accounts which have corresponding AccountShare records pointing to them, or are there limits with some customers on how far back getDeleted can go, such that I might not be able to confirm that a particular problem record is due to this particular problem? I believe I had a problem with a developer account on how far back I was allowed to go with getUpdated and getDeleted. Would customers have the same problem?

Customers don't like to see messages like, "357 errors occurred, and some of them may be due to the normal functioning of the system, but we don't know which ones or how many".  The customer was displeased to see this, and really wants an answer that makes better sense from a data integrity point of view.

John Saunders