Salesforce Files replaced Notes & Attachments, and are a vast improvement, however there are some areas which still need to be improved to bring the data up to the same level.
One area which is difficult is working out which records are related to Salesforce Records. Although not necessary on a day to day basis, this is necessary for audits and to analyse where/why all that storage is being used, amongst other examples.
The request: To remove the limitation on Data Loader, so that it is possible to extract all records from the Content Document Link object (also known as ContentDocumentLink) simply, without complex queries, via Data Loader, in one go.
Stretch goal: Improve the consistency of the Files related list, so that whenever a file is uploaded to Salesforce, the parent record is not listed as the User record, but the other record (e.g. Opportunuty, Account etc). At the moment if you upload a file in Classic, the parent record is the User record, but if you upload the same file in Lightning then the parent record is the other record. The Lightning behaviour is far more useful as there are a number of other ways to see who uploaded the file, but on Classic you have to do complex workarounds (e.g. vlookups) to work out the other related records.
Background - for those that want all the detail
Ok, so what’s going on here?
As a reminder, this is Files: (highlighted in the green box, below)
...and it can appear on any record within Salesforce. It’s useful for storing Contracts, signed documents, photos, manuals, and many other things. It also has a really useful feature in that you can create a Public Link, so that anyone outside of Salesforce with the relevant link can also see that same file.
But all these documents can build up, and occasionally you want to an inventory.
You can’t run a report showing which Files are attached to which records. The only way you can do it via via going to each record and seeing which Files are in the related list(!)
The closest you can get is a report using Report Type: “File and Content Report” which shows the files that have been published, but that won’t list everything. Usually all information is available via Data Loader or Data Export, so there are workarounds? Well, this is stretching the word “workarounds” in my opinion.
There are two useful objects where this data is stored:
Content Version (ContentVersion) which shows the core data and has no restrictions, but it only lists the first associated record via the FirstPublishLocationId column. This is useful if you happen to have uploaded the File in Lightning, where the associated record seems to be the main record (e.g. Opportunity, Account etc), but if you have uploaded the document via Classic for reasons unknown the FirstPublishLocationId will show the UserId; that’s the same UserId that is already shown in the CreatedById field/column.
ContentDocumentLink is the object where the details of all the records the File is related to is stored. However the error message you get when trying to extract all data is:
Implementation restriction: ContentDocumentLink requires a filter by a single id on ContentDocumentId or LinkedEntityId using the equals operator or multiple Id's using the IN operator. (as also shown in the first screenshot, towards the beginning of this idea)
Why is there this implementation restriction? I haven’t seen it for any other object. What useful benefit does it have? I’m suspecting oversight rather than anything more nefarious.
I am informed by Salesforce Help and Support that to get the record details out via this I would need to use additional queries within DataLoader such as
SELECT ContentDocumentId,Id,LinkedEntityId,ShareType FROM ContentDocumentLink WHERE ContentDocumentId IN ('0697F000006A3UqQAK','0697F000006A3UlQAK','0697F000006A3V5QAK')
This isn’t practical for Administrators as it’s rather a technical stretch, and a significant move away from the point and click ease of general building and maintenance.
So, the essence of this Idea/request: Can this restriction be removed, so we can get on with working out which Files are attached to which record, with ease.