Olexander is an avid tech enthusiast, deeply engaged in programming and discovering new IT technologies. He enjoys exploring various programming languages and uncharted technical areas, which he believes broadens his perspective and enhances his expertise. For relaxation and a change of pace, Olexander delves into the imaginative worlds of science fiction books.
get a quoteGetting started with Salesforce can be complex since the ecosystem and capabilities it provides have advanced over the years. One of the primary components Salesforce devs, admins, and architectures work with are files. They are features that allow users to store, manage, and share files within the Salesforce platform
In this post, Synebo engineers, with all our diverse experience and vast expertise, will shed light on Salesforce files, their types, Salesforce attachments vs files differences, architecture, and sharings of Salesforce files. We’ll also delve you into front-end and back-end perspectives on Salesforce files, notes, and attachments.
Salesforce files provide a centralized, cloud-based solution for storing and accessing various types of documents and multimedia files. Files in Salesforce are integrated throughout the Salesforce ecosystem, allowing users to attach files to specific records, collaborate on documents, and share files securely within and outside their organization.
The different aspects or types of file storage and organization within the Salesforce ecosystem are:
Salesforce files encompasses the management over the listed. As for the main Salesforce file types categorizing in all above mentioned, they are the following:
The main aspects associated with Salesforce files are:
Salesforce files represent a modern approach to document and multimedia file management, deeply integrated into the Salesforce ecosystem to support various business processes, improve efficiency, and enhance collaboration.
While files are more versatile, notes and attachments are more specific and focused on particular functionalities. Let’s take a look at the detailed comparison of files vs notes and attachments based on distinctive features they have.
Feature | Salesforce Files | Salesforce Notes and Attachments |
Storage Model | Unified storage detached from specific records. | Object-specific attachments tied to individual records. |
Integration | Seamlessly integrates with other Salesforce features. | Well-integrated, but may lack certain advanced features. |
Type Support | Broad support for various file types, including multimedia. | Primarily supports standard document formats and some image types. |
Backup and Recovery | Robust backup and recovery processes, often integrated with Salesforce’s overall data management system. | Backup and recovery dependent on Salesforce’s standard data backup procedures; may be less flexible. |
Cross-Object Reference | Easily associated with multiple objects. | Tied to a specific record; duplicative effort for cross-object references. |
Version Control | Supports multiple versions and version history. | Limited version control; lacks systematic tracking of changes. |
Search Functionality | Improved search capabilities with advanced metadata. | Basic search functionality based on file names and details. |
Collaboration Features | Enables collaborative editing through Salesforce Quip. | Basic collaboration; primarily focused on document association. |
Preview Options | Facilitates detailed organization with rich metadata. | Relies on basic file details for organization. |
Granular Organization | Enhanced options for organizing files with rich metadata. | Basic organization based on file details. |
External Application Dependency | Reduced dependency on external applications for file previews. | Often requires external applications for file viewing. |
Customization | Highly customizable with additional attributes and tags. | Limited customization options beyond standard fields. |
It’s important to note that there’s no discussion about what Salesforce documents to use, files, or notes with attachments. They are tools that devs, architectures, and administrators use when working with Salesforce as needed. So, this comparison serves the goal of understanding both concepts better to use them in the right way.
Are you looking for a Salesforce development provider to help you with your Salesforce solution? Reach out to Synebo and let’s discuss opportunities!
Now, let’s get to know Salesforce file management in several of its main aspects from the development perspective. It includes tips and how-tos helpful for all specialists working with the ecosystem.
In the Salesforce admin environment, files are displayed under the parent object realized with related list Notes & Attachments. From it, you can add a new file by clicking the “ Upload Files button .”
Alternatively, you can find all files that are accessible to you with additional categorization in the “ Files tab .” The “ Upload Files ” button is the same as on the previous screenshot.
After you choose the File, it will be uploaded. Then, simply press the “ Done ” button and the file will be successfully saved to your Salesforce org.
Additional file properties as well as support actions are available by clicking on the uploaded file. Here you can download or share the file, get a public link to it, view file details, upload a new file version, edit details of the file, and delete it.
Let’s proceed with the review of notes and attachments from the architecture perspective. In its basic form, the Salesforce documents data model looks like a chain of linked containers of data and its values. You can review the basic representation of the data model in the diagram below.
Each object from the presented diagram can be considered separately.
Basically, managing files and their relations in Salesforce are represented by three main objects, ContentVersion, ContentDocument, and ContentDocumentLink plus content data owner object. The mentioned objects appear instead of one “Attachment” object. Although the new data model is more complex, it gives us the ability to link a file with multiple records without duplicating binary data and provides greater flexibility. There is also version history that regulates object field changes.
Here are more detailed explanations to each object and version history:
It is the main object that directly stores the binary data of the file version. It’s also one of the most used objects when you are working with files.
In contrast to ContentDocument, this object supports the whole functionality of SObject (including insertion and adding new fields, restricted on ContentDocument). It contains most of the file version properties, file update history, etc.
It is an object that stores a reference to the latest published ContentVersion and its associated properties.
Content document is the main object from a data model perspective. It is the basis for all subsequent file life, manipulation, and creation of subordinate objects. You cannot find this object in the Object Manager from org Setup. But you still have the option to open it from the developer console. You cannot add new fields directly to it or programmatically create a record. However, you can use other DML operations and add triggers to it.
It represents an object that links a file (ContentDocument) to a specific parent record. Additionally, provides sharing and visibility properties. Once this object is created, the corresponding file will appear in the org UI as associated with the specified parent.
They represent the history of the ContentVersion and ContentDocument objects field changes. Both of them are read-only.
Content Data Owner Object represents the parent object of the file. As part of a data model based on the polymorphic LinkedEntityId field of a ContentDocumentLink object, can be an object with the type of most standard and custom objects.
Basically, a ContentDocument record can have multiple ContentVersion records associated with it. It gives us the ability to keep a version history of file data and quickly restore it to a previous state if necessary. But in the related list notes & attachments we will always see only one ContentVersion record, which is the most recent (IsLatest field is populated as true). There can be only one ContentVersion record associated with some ContentDocument in the system and marked as the most recent. This flag is filled in automatically by the platform.
Now that we have some general knowledge about file management objects, let’s talk about how to use them in a development context. We will also review the relationship of objects and some other nuances using excerpts from programmatic file creation as example.
Programmatically file creation starts from insertion of ContentVersion record.
The ContentDocument record will be created automatically as a part of the ContentVersion saving transaction and the corresponding ContentDocumentId will be populated on the ContentVersion record as well.
ContentVersion contentVersion = new ContentVersion(Title = 'NewFile', VersionData = Blob.valueOf('file content'), PathOnClient = 'NewFile.txt');
Database.insert(contentVersion);
In the example above, we have successfully created a new file in Salesforce. If we want to link the created file to any parent record, we need to create an instance of ContentDocumentLink. Note that after creating the ContenVersion object, we have to query its ContentDocumentId. The simple code example is shown below:
ContentVersion contentVersion = [SELECT ContentDocumentId FROM ContentVersion WHERE Id = :contentVersion.Id LIMIT 1];
// For instance, we have to bind created file with an Account named 'Test account'
Account testAccount = [SELECT Id FROM Account WHERE Name = 'Test Account' LIMIT 1];
ContentDocumentLink contentDocumentLink = new ContentDocumentLink(
LinkedEntityId = testAccount.Id,
ContentDocumentId = contentVersion.ContentDocumentId
);
Database.insert(contentDocumentLink);
With two small code samples, we created a new file in Salesforce.org and linked it to an Account record.
When searching (querying) a particular ContentVersion record, you must remember to filter the query by the IsLatest flag. For instance, if you want to find a file named “Contract 10.docx”, the query should look like this:
ListContentVersion> contentVersions =
[SELECT ContentDocumentId
FROM ContentVersion
WHERE PathOnClient = 'Agreement 10.docx'
AND IsLatest = true];
At the beginning of the post, we discovered where we can find the files and how we can create them. The “ Upload Files ” button in the standard user interface is generated by the platform and fully handles the file creation process under the hood.
if you need to add some custom button to upload files? This is where a component called lightning-file-upload lwc comes in handy. It handles file creation (inserting ContentDocument and ContentVersion) just like the standard UI and looks exactly the same:
HTML code here will be something like this:lightning-file-upload
label="Attach receipt"
name="fileUploader"
accept=
record-id=
onuploadfinished=
multiple
>
lightning-file-upload>
Javascript lwc side handles basic file upload operations and as a result, returns a detailed list of ContentDocuments identifiers in the onuploadfinished event.
Let’s have a brief overview of the main features of basic object-sharing management. More detailed information can be found in the file privacy and sharing official guide.
In ContentDocument and ContentVersion, we have the same fields with picklist types which are SharingOption and SharingPrivacy:
In the ContentDocumentLink object, we have ShareType and Visibility fields relevant to the topic under discussion:
Need a trusted Salesforce consulting firm? Contact Salesforce specialists from Synebo and let’s discuss!
lightning-file-upload label="Attach receipt" name="fileUploader" accept= record-id= onuploadfinished= multiple >
Salesforce File Limits
Since all areas in Salesforce have some limitations, files are no exception. While it may not be the most fascinating subject, understanding these limitations is crucial to prevent unexpected ‘limit’ exceptions. Here’s a more detailed look into this area:
File size and sharing limits:
General requirements for them are described in the article File Size and Sharing Limit .
Salesforce CRM Content Limits:
General requirements for them are described in the article Salesforce CRM Content Limits .
Apex Governor Limits:
General requirements for them are described in the article Apex Governor Limits .
Each of these limitations plays a vital role in ensuring the smooth operation and management of files and resources within the Salesforce ecosystem. Familiarity with them is essential to prevent system errors and optimize the platform’s use.
Since the technology is a bit complex, you may face some issues when utilizing it. Let’s take a look at common files challenges and recommended ways to solve them:
Problem description: We need to update some of the existing ContentVersion fields. At the same time, we need to get the VersionData value (without any updates).
Update DML operation failing with an error – “INVALID_STATUS, You can’t set the VersionData when IsMajorVersion is true”.
Tips to solve it: To get around this problem, we can simply nullify this field before calling the DML update operation. And yes, it doesn’t affect the saving ContentVersion record, which means that even if we set null in the VersionData field, it won’t change anything.
Problem description: An error occurred when uploading some files to the third-party DMS (Database Migration Service) using Rest API. The error was the next – “String length exceeds maximum: 6000000”.
Tips to solve it: It turned out the problem was that integration was using multipart/form-data content type, and the HTTP request body was manually defined as a string. When the large file was converted to a string using the base64Encode() method, we got an apex error according to the string variable limitation. This means that you need to remember that if you convert the blob file data to a string, the maximum file size you can use is about 4.3 MB.
But it is better to use a variable with type Blob if possible. For example, if we need to send data through an HTTP request, we can use the setBodyAsBlob() method of HttpRequest, which takes a blob as a parameter. Blob variables have no such restrictions, and you will not face this error.
Looking for a trusted Salesforce consulting partner ? Reach out to Synebo and let’s discuss opportunities!
If you manage it to the end, accept our personal gratitude! Now you’re knowledgeable about Salesforce files and their types, Salesforce attachments vs files differences, architecture, and sharings of Salesforce files from the UI and dev front-end and back-end perspectives.
Our next how-to articles will be about the topic of Salesforce documents: Internal and external links and Salesforce files: Utilizing Platform APIs. Contact Synebo should you require any development assistance, and stay tuned to new blog updates.
How can I access Salesforce Files?To access Salesforce Files, use the Files tab to view, search, and manage all accessible files, or check the Notes & Attachments related list on records like opportunities and contacts for specific file attachments.
How can I add files to Salesforce?You can add files to Salesforce by uploading them directly through the Notes & Attachments related list on records, using the Files tab, attaching them to Chatter feeds, or having them shared with you.
Does Salesforce keep track of different versions of files?Yes, Salesforce tracks different versions of files. When you upload a new version, the old versions are retained, allowing you to view, download, and revert to them if necessary.
How can I collaborate on files with other users?To collaborate on files with other users, share files with specific users or groups, use Chatter to comment and @mention colleagues, enable file syncing with Salesforce Files Connect, and set up file access permissions for control.