If you are considering deleting email-to-case attachments, here are a couple of considerations. First, you need to determine if the email-to-case process is set up to generate Attachments or Files. Salesforce Files replaced attachments and are now the recommended approach as they are shareable and searchable.
Email-to-case Configuration
To see how the email-to-case process is configured, simply navigate to Setup -> Feature Settings -> Service -> Email-t0-Case
If Save Email-to-Case attachments as Salesforce Files is checked, email attachments are saved as Files. Otherwise, they are saved as attachments. If saved as attachments, you should consider moving to files, including converting old attachments to files.
Files in Action
Let’s look at a scenario where Save Email-to-Case attachments as Salesforce Files is checked. In this example, we will send an inline image (the LinkedIn icon) and an attached image (the yellow dog head) to our email-to-case email address.
Once process in Salesforce, the email-to-case process generated a case. In addition, both the LinkedIn icon and the Yellow Dog Head were generated as files. Note: The Related list is labeled “Attachments”, but these are indeed stored as files in Salesforce.
Let’s Take a Look Under the Hood
When an email is processed via email-to-case (and Save Email-to-Case attachments as Salesforce Files is checked), an EmailMessage record is generated. A ContentDocument record (and a child ContentVersion) is created for each email attachment. The ContentDocument record is related back to the EmailMessage record via ContentDocumentLink.
Let’s Confirm That With Some SOQL
In this example, the Case Id created by the email-to-case process was 5005f000008GpqmAAC.
To Find the Email Message(s) Related to a Case
select id from emailMessage where parentId = ‘5005f000008GpqmAAC’
This returns Id=02s5f000000baOOAAY.
To Find the ContentDocument(s) for the EmailMessage Id
select id, contentDocumentId, linkedEntityId from contentDocumentLink where linkedentityId = ’02s5f000000baOOAAY’
This returns the to ContentDocument records (the LinkedIn icon and the Yellow Dog).
(1) ContentDocumentLink:{Id=06A5f000004ajxfEAA, ContentDocumentId=0695f000003UG13AAG, LinkedEntityId=02s5f000000baOOAAY}
(2) ContentDocumentId=0695f000003UG14AAG, LinkedEntityId=02s5f000000baOOAAY}
Now, Let’s Delete the Record(s)
I see this common mistake often. Custom logic only deletes the ContentDocumentLink record. Remember, the ContentDocumentLink represents the relationship between a file and its entity (in this case, the link from the document to the EmailMessage). It does not delete the document itself. Here is what you typically see as a result of a ContentDocumentLink only delete.
The documents disappear from the Related Attachments. This is because the link between the documents and the EmailMessage have been removed. The file, however, has simply been orphaned. To make matters worse, the inline document reference (the LinkedIn icon) is a link to the ContentDocument (i.e. it does not rely on the ContentDocumentLink).
To confirm this, you can look at the underlying HTML which points to the ContentVersion record.
So, How Should the File Be Deleted?
In order to delete a file from both the reference and the related list, the ContentDocument must be deleted. Deleting the ContentDocument will delete all ContentVersion and ContentDocumentLink records associated to the ContentDocument. Deleting the ContentDocument will result in a view like the following:
The inline reference no long points to a valid File and no attachments are linked to the EmailMessage record.