How to Work With Salesforce Files: The Basics

Getting 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.

What Are Salesforce Files?

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:

1. Documents. This term generally refers to traditional file formats used in business environments, such as Word documents, PDFs, and spreadsheets. In Salesforce, these are the types of files you might store and manage using various features, including Salesforce files.
2. Content. In Salesforce, “Content” can refer to rich media files, including videos, images, and audio files. These are the types of files that might require more storage space and bandwidth, and Salesforce provides tools to manage and share these files effectively, especially for marketing and communication purposes.
3. Libraries. Within Salesforce, Libraries are used to organize files in a structured way. They allow users to categorize and store related files together, making it easier to manage and access them. 

Salesforce files encompasses the management over the listed. As for the main Salesforce file types categorizing in all above mentioned, they are the following:

• Documents: Word processing files, PDFs, and text files.
• Spreadsheets: Excel files and other spreadsheet formats.
• Presentations: PowerPoint presentations and similar formats.
• Images: JPEG, PNG, GIF, and other image formats.
• Videos and audio files: Various multimedia formats.
• Other file types: Depending on the Salesforce configuration and integrations, it can support a variety of other file types.

The main aspects associated with Salesforce files are:

• Integration with Salesforce records: Files can be linked to specific Salesforce records, like attaching sales presentations to opportunities or manuals to product records, providing contextual relevance.
• Collaboration and sharing: Users can collaborate on files through commenting, liking, and sharing, enhancing teamwork and communication within Salesforce.
• Versioning: Salesforce tracks different file versions, allowing users to view and revert to older versions, ensuring data integrity and maintaining a change history.
• Permissions and sharing settings: Access controls and permissions can be set by administrators, specifying who can view, edit, or delete such Salesforce documents, thus protecting sensitive information.
• Chatter integration: Files integrate with Salesforce Chatter, enabling sharing in Chatter feeds and fostering a social collaboration layer.
• Search and discovery: Robust search features allow for efficient file location using metadata, keywords, or content.
• Salesforce connect: Enables access to files through Salesforce Connect, linking external data sources and displaying files from external systems within Salesforce.
• Mobile accessibility: Files are accessible on mobile devices, supporting on-the-go access, viewing, and collaboration.
• Analytics and Reporting: Salesforce offers reporting and analytics for files, tracking usage, views, and other metrics.

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.

Difference Between Files vs Notes and Attachments Salesforce

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.

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!

Salesforce File Management: UI, Architecture, and Development Perspectives

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. 

Salesforce Files in UI

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.

Architecture of Salesforce Files

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: 

• ContentVersion

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.

• ContentDocument

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.

• ContentDocumentLink

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. 

• ContentVersionHistory and ContentDocumentHistory

They represent the history of the ContentVersion and ContentDocument objects field changes. Both of them are read-only.

• Content Data Owner Object. 

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.

Notes & Attachments From the Back-End Development Perspective

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:

List<ContentVersion> contentVersions = [SELECT ContentDocumentId  FROM ContentVersion  WHERE PathOnClient = 'Agreement 10.docx'    AND IsLatest = true];

Notes & Attachments From the Front-End Development Perspective

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={acceptedFormats}             record-id={myRecordId}             onuploadfinished={handleUploadFinished}             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.

Sharings in Salesforce Files

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:

• SharingOption can be set to “Allowed” and “Restricted” (corresponding values “A” and “R”, default is “A”). In the UI, it is represented as a checkbox named “Prevent others from sharing and unsharing”. Controls whether the file sharing will be frozen. 
• SharingPrivacy can be set to “Visible to Anyone With Record Access” and “Private on Records” (corresponding values “N” and “P”, default is “N”). Controls file sharing privacy.

In the ContentDocumentLink object, we have ShareType and Visibility fields relevant to the topic under discussion:

• ShareType can be set to “Viewer,” “Collaborator” and “Inferred” (corresponding values “V”, “C” and “I”). Pay attention, this field is mandatory. Indicates the type of permission granted to the user when sharing the file.
• Visibility can be set to “AllUsers,” “InternalUsers” and “SharedUsers”. Indicates whether the file is available to all users, internal users, or shared users.

Need a trusted Salesforce consulting firm? Contact Salesforce specialists from Synebo and let’s discuss!

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:

• Maximum file upload size. Restricts the size of files that can be uploaded in Salesforce, varying by the method of upload (e.g., via Chatter, communities, or as attachments).
• Sharing capacity. Governs the number of files and the extent to which they can be shared within the Salesforce environment.

General requirements for them are described in the article File Size and Sharing Limit.

Salesforce CRM Content Limits:

• Storage capacity. Determines the total amount of data storage space available for files and CRM content.
• File type restrictions. Specifies the types of files that are permissible within the CRM, impacting both storage and security protocols.

General requirements for them are described in the article Salesforce CRM Content Limits. 

Apex Governor Limits:

• Total Heap Size. Sets the maximum memory space that Apex code can consume during execution, crucial for ensuring efficient resource usage and preventing system overloads in different contexts.

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.

Navigating Salesforce File Challenges

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:

Tackling VersionData Errors

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. 

API Integration Hurdles

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!

Final Take

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.