Skip to main content
Nintex Community Menu Bar

I read through the tutorial Using The File Component to Attach Files to a Record (Page Not Found — Skuid v15.1.6 Documentation). It all makes sense and it works fine to upload a document. But for viewing, it would be ideal to be able to make use of the way Salesforce previews Chatter Files, as it’s visually more appealing than opening an attached document in a separate browser tab/window. But am I right in thinking that that’s not possible because you’re storing the file in the old Attachment object, rather than the Chatter Files data structure? And is that the longer term plan?

Yes, we definitely want to have a better way of previewing files on the same page in the future (I personally do not like clicking all the way through the Salesforce file pages). You can do some of this right now/soon by building your own popups, but it would be really great to have previewing preferences built into our file component. So you think the Chatter Files data structure would be better for this? Do you have any more ideas/advice about how we could best do this?


File previewing would certainly be nice to have. I’m pretty sure the way Salesforce does it isn’t available in Visualforce components, so I guess Skuid will need to do something from scratch. Salesforce is Flash-based anyway, which isn’t ideal. Javascript based would be preferable. Re the data structure, I’m pretty certain that the Chatter Files data structure is very much strategic for Salesforce, whereas the Attachment object isn’t. If Skuid uses the Chatter File structure, that would give us more confidence that as Salesforce continues to improve its Chatter UI (perhaps with better Visualforce components) we’ll be able to leverage those improvements within Skuid.


That sounds really great… we are definitely trying to make sure we’re at the front of all Salesforce UI developments (especially re: Chatter. 🙂


Thought I’d fill you in on how I’ve addressed this for now. I want to use the Chatter Files data structure for the sake of future proofing, and I want users to be able to preview files. So my Account View page (built from your Account View Starter Page) has a new model called ContentDocuments, which is based on the ContentDocumentLink object. This returns the Chatter Files associated with the Account. I then created a template field in a table on that model to have a link to the file preview page, which I open in a new browser tab. It’s not perfect, but it’s quite usable for now. Users upload files through the Feed tab, just as in normal Chatter. Again, not perfect having the file list and the upload button in different tabs, but the benefits outweigh this, if only just. I’ll share the code when I get a moment.


Thank you so much for sharing this, Glenn! Really helped me out.


Can you please post the code? I am getting an error 2. An error occurred while attempting to perform the following SOQL query: SELECT Id,LinkedEntity.Name,ContentDocumentId FROM ContentDocumentLink LIMIT 101 Error:Implementation restriction: ContentDocumentLink requires a filter by a single Id, ContentDocumentId or LinkedEntityId using the equals operator


Hi Chris … the page that I have this in is huge. I could post it, but it would be challenging to interrogate. That error you report is correct and as expected. The Chatter objects have certain implementation restrictions and to use ContentDocumentLink, you have to pass in an Id to filter it. My page is an account view page, so I filter mine on LinkedEntityId equals my account Id. Hope that makes sense.


Any update on moving to support Chatter Files data model for the files component in Skuid? It’s remarkable how bad regular attachments are in Salesforce and just making that switch makes the usability much greater for the user. Updating the Files component would allow for much cleaner interface for handling this (eg the difference between a file upload button with instructions and an instruction that says “go to the chatter tab and attach the appropriate number of files using the File tab…”).


We have not implemented this yet,  though it remains in our backlog.  We’ll get to it at some point.  We promise… 


What level of effort do you think it would be to get a new component that uses Chatter Files but otherwise behaves like the existing Files component? And is that something you would support? Wondering if this can get done sooner with some community and/or customer collaboration.


Chris! It is good to see you on the Skuid community! Bummed to have missed you guys at Decompression this year!

- Kaede


We totally support customers building new components.  We feel Skuid is a platform tool and we really want it to be used that way.  Now we probably can’t do a lot of hand holding along the way,  or else we’d just up and build it ourselves…  We also have to admit that our API docs are not as complete as they should be.  There is a lot of component building goodness that is API ready - but is not documented yet.  We’re working on it…

Having said all that - we’d love to see you go to town on a component and feel free to post your questions and your progress here. 


Rob, thanks for the response. We’ll give it a shot. I still can’t get your default file upload component to work attaching a file to a record anywhere, so kind of limited on understanding of that UX. Also, some details would be helpful about the builder property types on this page: http://help.skuidify.com/m/11720/l/129359?data-resolve-url=true&data-manual-id=11720


The major implementation barrier with the Skuid File component right now is that you can only use it to attach files to records that are already saved. If the record that you want to attach to is already saved, it should work fine. If you are using the File component as part of a Wizard process that is used to create brand-new records, and you want to attach Files to your new record(s), you will need to (1) save all of the new records before navigating to the step containing the File component(s) and (2) Set your Wizard Component to use the “Defer Rendering of Step Contents” property.