I should specify that I am uploading to Chatter. Thanks.

Currently no, there is no way to do this. I’m converting this to an Idea that is Under Consideration.

Thanks, Zack. Ideally, an upload would act as a new row trigger for actions on the ContentVersions object. That would solve the problem and more. Currently it only triggers a requery of ContentVersions which is helpful, because you can use that requery as a trigger for row update, but you have to update all rows in the model. If it triggered new row actions, you could populate custom fields only for the new row. Thanks!

Raymond, thanks for the feedback here, good ideas. We are considering adding various Action Framework hooks to the File Upload component, to allow you to specify custom sequences of Actions to run in response to particular File Upload component events.

Building on this, I think it would be valuable to have a Skuid component (or at least a tutorial) called “Files” that would do the following: 1) include a table based on ContentDocuments Object with a condition that limits records to those that have LastPublishedVersion/FirstPublishedID equal to the ID of the chosen model. 2) a file upload component on the same model 3) a delete button on the table rows (deletion can only be done on ContentDocuments Object) 4) an edit button that would open a popup displaying a field editor of the ContentVersions Object with the context of the Content Version ID from the row (edits to read/write fields can only be done on the ContentVersions object) 5) a secure delivery row button that would create a new row on the ContentDistribution object and populate it with the ContentDocument ID of the row and the name of the ContentDocument and an expiration date. 6) a table based on ContebtDistribution displaying existing Content Deliveries 7) a button for “make available for Content pack” which requires a new field to be created on ContentWorkspace object that populated the ID of an available library (chatter files have to be contributed to a library to be included in a content pack) a table based on ContentWorkspace that displays files in the specified library that are available for content packing. This will streamline just about everything Content other than the actual content packs which are not available via API.

One more comment thought on this: ContentDocuments Object seems to display all files linked to a record via the chatter feed function (files using Skuid uploader set to chatter feed), but in read-only. ContentVersion seems to display only records that the current user has read/write privileges which are files they own, or files that were shared with them in a library. So if user A uploads a file with the Skuid uploader set to chatter, user B will be able to see the file in a table on the ContentDocuments object, but won’t be able to edit it. User B will not see the file in a table on the ContentVersion object unless that file was contributed to a library that user B has access rights to or has been shared the file by user A. Consequently, it may be best to keep the view and edit functions separate as you set up the tables and field editors so that all users can see all files linked to a record AND be able to edit records they have read/write privileges on

Revision: regarding editing, instead of editing a row on ContentVersion, the process to be to create a new row on ContentVersion. This allows anyone with access to the ContentDocument row to “edit” standard and custom fields by creating a new version of the document that then becomes the “LastPublishedVersion”.

Sharing of files can be managed using the ContentDocumentLinks object. Create a new row on this object to link the the file to ANY record on ANY object including users and groups. Creating a table on ContentDocumentLinks will allow you to display all sharing access points to the file and the ability to delete any sharing access point through deleting the ContentDocumentLink row.

I was wrong, you can’t add a new version without uploading a doc. Instead I created an edit function that opens a pop up that displays a field editor on ContentVersions object that displays LatestPublishedVersion in edit mode. Works great so far.

I’ve got everything running smoothly now. The final hurdle was sharing. If user A uploads a chatter feed file on an account and User B has access to that account, in the Salesforce File tab, the record will be accessible to User B. However, I could not get Skuid to pull in these records created by other users. The API seems to only pull in records owned or that have been explocitly shared with the user through libraries or sharing. I settled on creating a library for each of my Accounts and grabbing the Library Id, pasting it into a field on the Account record, then creating a formula field on contacts called “Account Library Id” that is equal to the Account Library ID. Now when I upload a new file and the requery of ContentVersion models occurs, I use that as a trigger to create a new row on the ContentWorkspace Object that populated the ContentDocumentId (of the uploaded document) and the Library Id equal to the Library Id that I assigned to the Account. Now I just have to do a one-time set up where I add users to specified libraries related to the accounts they work with. This too can likely be automated, but I didn’t check. Sooooo… Based on this, to accommodate sharing, I would recommend that Skuid uploader have 2 additional settings: 1) Add to library based on merge syntax (new row on ContentWorkspace object) 2) Link to Entity based on merge syntax (new row on ContentDocumentLinks object). This allows the file to be linked to any record of any object, or libraries, or users, or groups.

I also create a “folders” object and related it to ContentDocument Versions. This gives me more formalized structure than tags. I have created some stock folders and shared then across the organization, but users can create their own as well. Folders work for organization plus as extra layers of permissioning if needed.

Lastly, I created a simple version of the file manager which I place in record detail pages and limit the records to just those pertaining to the record. I also created an advanced version that allows for view, edit, delete, sharing, contribution to library, and content delivery of all files the user has access to which is so much easier to use and understand than the Salesforce user interface for content (in my opinion)

Thanks for documenting these ideas so extensively.  Lots of good stuff here to chew on…