In this post, we will discuss the concept of orphaned files. Before we get started, however, let’s touch on the difference between Attachments and Files. (Note: A discussion on the differences between Attachment and Files could fill pages. This is a quick review to introduce the concept of Orphaned Files).
What’s the difference between Attachments and Files?
With Attachment records, the attachment represents a document and is related to a parent object (such as an Account record). When the parent object is deleted, the attachment is also deleted.
With Files, Salesforce introduced a much richer entity relationship. At its base, a File consists of a ContentDocument, ContentVersion, and ContentDocumentLink. The ContentDocument represents the document. The ContentVersion represenst a specific version of a document. The ContentDocumentLink represents the relationship between the document and its parent(s).
This improved structure provides a number of enhancements over Attachments, including improved sharing capabilities, reduction in file storage, version control, etc. But it also introduces the threat of orphaned files.
What is an orphaned file?
The ContentDocumentLink object provides the ability to link a single document to many parents (referred to as linked entities).
Let’s look at an account named Random Account as an example. This account contains a file entitled Discovery Notes.
Clicking into the file sharing details, we see that the file is linked to two entities; the user that uploaded the file, and the account the file was uploaded.
Next, we delete the Account and reexamine the file sharing details.
The account is deleted, the content document link to the deleted account is removed, but the file remains linked to the user that uploaded the file.
This is an orphaned file.
Wait. Is that really an orphaned file?
Well, that’s truly a question to be answered by the business. In some cases, business requirements dictate that the file should remain. In others, since this is a document specifically related to the Account, it too should be deleted.
If the business considered this situation an orphaned file, these files are addition instance clutter, eating up valuable file storage space. Let’s take a look at resolving these orphaned files.
Ok, how do we deal with Orphaned Files?
Here at Sproket Logic, we recommend a two-pronged approach.
(1) Deal with orphaned files retroactively
(2) Deal with orphaned files proactively
(1) Deal with Orphaned Files Retroactively
If you have spent any time with ContentDocuments, you know that they can be problematic. Salesforce limits the ability to report on, query, and generally process ContentDocument records. As a result, dealing with Orphaned Files retroactively requires a custom approach.
Before we get started, make sure your running user has the Query All Files permission (Query All Files (salesforce.com). Do not assume the System Administration can see all files by default. They too must have the Query All Files permission.
Next up, we install the Sproket Logic Orphaned Files app to provide customizable configuration, batch jobs, and reporting to analyze and finally purge your orphaned files. (Don’t worry if some of this content is confusing. This is information only. The Sproket Logic team will help navigate the setup and processing for your unique business requirements.).
(a) The Orphaned File Setting CMDT provides configuration options to pinpoint the business’s specific requirements.
| Option | Notes |
| Ignore Object Names | Configuration allows for the definition of remaining linked entiti(es) which identify an orphaned file. By default, a file only linked to a User is considered orphaned. |
| Additional Where Clause | Configuration available to further filter content documents. For example, limit the search to .pdf files only. |
| Purge Addition Where Clause | Configuration available to further filter the purging process. |
| Clean Addition Where Clause | Configuration available to further filter the cleaning process. |
(b) The Orphaned Files analysis process reviews your instance to identify orphaned files. Upon completion of the Orphaned Files analysis process, results can be reviewed in a dashboard.
This analysis stage provides an opportunity to review the results, identify potential causes for orphaned files, and, finally, the option to tweak the configuration before making any purging decisions.
(c) The Orphaned Files purge process purges orphaned files from your instance.
(2) Deal with Orphaned Files Proactively
Once your instance has been cleaned retroactively, you can decide how to deal with orphaned files moving forward. One option, simply execute the above retroactive analysis on a periodic basis. A second option, implement triggers/automation to identify these situations as they occur. The Sproket Logic team is ready and able to assist.
To find out more about our orphaned files approach or to discuss additional requirements, give us a ping at [email protected].