In this post, we will discuss the concept of Content Versions (and its potential impact on file storage). 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?
Attachments and Files are both mechanisms to store files/documents and relate them to parent(s). Attachments are technically depreciated in Lightning Experience. However, they can still be leveraged (at the moment).
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.
What’s so special about Content Version?
One of the biggest benefits of Content Version is the ability to maintain multiple iterations (versions) of a document. Let’s take a look at how that works.
You have developed a presentation for your company.
You upload the file. When you view the file in your instance, you can see that it creates V1.
While reviewing your document, you discover an additional “.” that is unnecessary. You resolve the issue and upload a new version. Once again, you review the document and discover that “Cat” was misspelled. You resolve the issue and upload another new version. Now, upon inspection of the file, you are able to see the latest pristine version of the document. In addition, you are able to view all the previous versions and your version notes.
This functionality can be extremely important for a variety of documents. For example, maintaining yearly changes in a PTO policy. Or the ability to review iterations of a contract negotiation.
Great! So, what’s the problem (as it relates to file storage)?
The Content Versions object stores the record of your edit notes and the complete version of the file. In our Cat example, this means we are storing the final clean v3 at 2.3MB, v2 at 2.3MB, and v3 at 2.3MB for a total of 6.9MB. Now imagine the storage footprint of a large powerpoint file with 15+ versions. And now imagine the storage impact of hundreds of large powerpoint files with 15+ versions.
Ok. That could be a problem. Anything else we need to be aware of?
Well, it’s important to note that ContentVersions cannot be deleted. Only a file (and all of its versions) can be deleted.
Interesting. If we are experience File Storage issues and believe Content Versions is a part of the problem, what can we do?
First up, we recommend installing our Version Killer (Free) app from the app exchange. Within a couple of minutes, you can generate an analysis of your Content Version footprint. The app will produce a report similar to the following.
Next, engage with the Sproket Logic team to perform a deeper analysis of you instance. Our team can help reduce you file storage footprint by:
- Identifying unnecessary files and/or content versions
- Identifying best practices to reduce versions
- Identifying additional audits
- implementing custom functionality to remove unnecessary files
- Implementing custom functionality to remove content versions
To find out more about our content version approach or to discuss additional requirements, give us a ping.