Files & Attachments in Lightning Experience

Recently Salesforce published this alert about Attachments being replaced by Files in Lightning Experience. What the alert says is that Salesforce is starting to retire Attachments, which at some point will be replaced by Files. By now, the immediate consequence is that Attachments are not searchable in Lightning Experience.

Fortunately, there is a setting called “Files uploaded to the Attachments related list on records are uploaded as Salesforce Files, not as attachments.”, that configures your org in order the attachments that you upload on the attachments related list are stored as files (and thus are searchable in Lightning Experience).

What I have done to test this alert consequences is:

1. Upload attachment A to a specific record

2. Activated “Files uploaded to the Attachments related list on records are uploaded as Salesforce Files, not as attachments.” in customize -> salesforce files -> general settings, as it’s recommended in the alert.

3. Upload attachment B to the same record – which now is stored as a file

The results are:

In classic:

• I can see both A and B in the record related list
• I find both A and B in search results

In Lightning Experience:

• I can see both A and B in the record related list
• I can find B in search results, but I can’t find A

This is, if you activate the setting above, docs uploaded since the setting is activated will be searchable in Lightning Experience, however legacy attachments won’t show up in search results.

Then there are two things you should take care about:

1. You may want to migrate legacy attachments to files, in order they are searchable in Lightning Experience.
2. If your code creates Attachments programmatically, you should change the code at some point to create files instead of attachments.

Creating files programmatically is not as straightforward as creating Attachments. We have several objects that represent Files in Salesforce:

• ContentDocument: the one that stores the files
• ContentVersion: the one that stores the versions of the files
• ContentDocumentLink: the one that stores the relationship between the file and entities on the org. For example:
  • Link to the user who uploaded the file
  • Link to the record to which a file is linked

Inserting records in ContentDocument table with DML is not allowed. Salesforce help says the next:

To create a document, create a new version via the ContentVersion object without setting the ContentDocumentId. This automatically creates a parent document record. When adding a new version of the document, you must specify an existing ContentDocumentId which initiates the revision process for the document. When the latest version is published, the title, owner, and publish status fields are updated in the document.

So, in order to create a file, what we have to do something like the following:

 

I found this fantastic tool developed by Doug Ayers which can do the migration for you.

Check special access rules to these objects. Worth to point out the next rule:

In API versions 33.0 and later, you can create and delete ContentDocumentLink objects with a LinkedEntityId of any record type that can be tracked in the feed, even if feed tracking is disabled for that record type. Chatter must be enabled for the organization.

So, if we are creating files linked to a record, from API 33 we don’t need feed tracking to be specifically enabled for the record.