We just launched native support for images in cells - see Launched: New Image Column Type is now available
7 Likes
Nigel & Jamie, the images feature is a great step in that direction. I know you guys have a unique design philosophy, but a lot of the people who are moving over from Airtable and/or Notion are going to find this to be a necessity.
Jamie asked for refreshed use cases. I have one that’s holding me back at the moment - I can’t add attachments to tasks. I’m trying to migrate from Wrike to coda because of everything coda does so well. I can embed or link, but it’s really crucial that the attachment be contained within the task for data/trust reasons.
As well, above, someone mentioned a page view, which also basically comes from Notion. You have a basic page view of a row right now and it’s heading that way. I don’t see how coda could do the same thing Notion does, but that’s fine, it’s not the same product. With the ability to attach files in a cell, beyond images, I think you’re basically where you need to be.
If we reverse it from a business rules angle, one of the more obvious recommended templates is tasks. The core elements of all modern task management apps are within coda’s capabilities now. The only one missing is the attachments.
With that said, coda’s a very robust and interesting app. I’m only about a week into it, but it’s closest to something I spec’d out a while back that does 80+% of what I need. Your continued rollouts and work are appreciated - so thanks!
Hi, My 2 cents here to vote this topic:
it is extremely important to replicate what has been done for images also for files (PDF, .docx, .pptx, etc…).
I really would like to format a column to “file” (potentially reagardless of the type, if it’s an image, pdf, word,ppt…the system should recognize it based on the extension) and hence being able to preview/navigate them (pretty much how it happens for images now).
Using “embed” is not sufficient! It is cumbersome and most of the time i’m dealing with local file system/email attachment.
PLUS… and it’s not the least:
a column that is a “Section/page” itself would be the game changer here so I can have a free canvas inside a cell (like Notion does)
When you guys will implement that I’m sure you’ll win the game for the new Makers how your CEO says 
any timelines?
7 Likes
Images is a good step!
Definitely want files too though e.g. for a task backlog, attaching a relevant csv / xls dataset
1 Like
I couldn’t find more recent threads on attaching files, so I thought I’d bump here - any news?
One proposal for the PDF feature is to include citation extraction so as to replace zotero & mendeley.
2 Likes
Definitly need this too.
Any timeline ?
3 Likes
Basic file repositories are just that… a basic requirement. This is an absolute show stopper for us and I’m sure we are not the only one. Coda is a tool that should enable us to bring all the ‘things’ together. Is there a reason only image uploads are supported over all file types?
2 Likes
@Adam_Abbott I imagine that until they have a pricing model, allowing unlimited uploads causes more problems than its worth from a hardware and support standpoint.
That could be solved with fixed size limits per account/file.
2 Likes
Any update here yet?
2 Likes
I hate attachments in all the “normal” Task/Project management services. It just take ages to upload everything or navigate through tasks.
Coda is really cool with images copy/pasting directly to doc or cell.
What I’d prefer instead of messy attachments - is ability to quickly edit multiple selection if images. Let say you uploaded 10 images and can quickly resize them all in connection to each other.
In terms of attachment - embedding of Google Drive or Dropbox folder is way to go.
Especially now, when Google Shared Drives has unlimited space (why spent money on Coda for that?)
1 Like
I finally ran into this as well when we started using the system for project management.
For us, the ideal situation would be a way to integrate it with the Google Drive Pack.
Features we need:
- Arbitrary attaching of files to Sections
- Attaching files to rows
- Ideally, if integrated with the Google Drive pack, for a specific column on a specific table the ability to specify a target folder and have any attachments immediately uploaded there.
3 Likes
We’re finding it really difficult to integrate workarounds based on GDrive and Dropbox. Our teams need to create workflow and process around GDrive structures, governance etc, then upload there, pull links, attach those to objects.
It would be great if we could just see native file uploads come to Coda without intensive workarounds.
1 Like
You mean like - whenever a document is added to a specific Drive folder, add the [secure] link to that document into an existing or new row in a Coda table? Basically - sync the contents of folder (x) into table (y)?
I would like the opposite…
drop a file on a row in Coda.io and the save it to a specific folder in Drive (good for large files, otherwise the coda document would be to large)
2 Likes
Meaning that we need team members to actually leave the doc, create something and a structure on a google drive and then come back with a link. Its not just the process of having to move off of Coda, its that you need additional layers of SOP around governance, admin and maintenance of Google Drives. When in actual fact in most cases a table with attachments and some simple process is self servicing.
1 Like
Understood. Thanks for helping me see this.
In a few cases I’ve overcome some of the manual tasks that stand in the way of a seamless creation of the connective tissue between Drive and Coda docs, but it’s presumptive and extremely rigid.
GAS, Tags, and Google Drive Change Events
For example, imagine a script process that watches for change events occurring in Google Drive concerning files that contain hash-tags embedded in the documents (or in the document description meta).
Whenever a change in a document that matches the tagging scheme occurs, update a row in every Coda doc where that Google Drive document is represented. If a new Drive document is created that possesses the tag scheme pattern, instantiate the representation of the document in all Coda tables where appropriate.
While this automation approach works really well and eliminates a great deal of the process requirements (i.e., SOP around governance, admin and maintenance as you point out), it requires significant effort to build and define the process rules to make this happen with precision. There’s nothing ad-hoc about it - it’s a machine that performs steps to synchronize visibility - links to Drive documents about (x) appear in Coda tables (a, b, c) about (x).
It’s presumptive in that it fails to embrace any level of security in the context of discrete users, and it assumes document creators fully understand the ramifications of the tag scheme, a potentially dangerous automated sharing proposition.
Clearly Way Off-topic Now
But it does underscore one of the few cases where Google Apps Script can be applied in a non-polling way to sustain real-time connectivity between Drive documents and direct access to those documents in Coda tables and even embedded content.
Why would I even go to this trouble?
Money. People pay me to do whacky things.
I’ve used this approach to create a search abstraction layer inside a Coda document; indeed, across many Coda documents. The business requirement was simple -
… make it possible for Coda users to search [inside] Coda docs to find and access Google Drive content.
Creating seamless findability for documents in Google Drive seems oxymoronic. After all, it’s Google. 
But this requirement runs deeper than search - it’s about effortless embrace and seamless accessibility of documents external to Coda - literally to your point.
How
- Watch for change events in a Drive folder (or across all documents that match a specific pattern).
- When a document matches the pattern, harvest the content and create a full-text (compressed) keyword index.
- Update the document’s security setting to “has link”.
- Upload the document’s title, meta-info, URL, and keyword index into the target Coda tables.
- Create a change log record (another Coda table summarizing Drive-based document updates).
My approach does all of this seamlessly and in the background with Google Apps Script. However, it’s not a bed of roses and hopefully, this exposes to the Coda developers some of the drawbacks of making so many presumptions in such a process.
2 Likes
This really is a very high priority requirement for us. Like one of the posters said above a year back, there’s a lot of things you can’t do with Coda now, like:
- Recruitment management (can’t upload resumes)
- Financial management (can’t upload scanned invoices or receipts)
- Content production (can’t upload designs and design revisions)
- Share files with clients (can’t upload PDFs)
I’ve mainly used Airtable for our content production for the last couple of years. The attachment and file previewing features in there is really awesome, and I think they just use the API from FileStack (https://www.filestack.com/) instead of trying to build it themselves.
One of the biggest limitations in Coda right now (even with the image field) vs. Airtable is that in Airtable, you can just drag and drop as many images/videos/PDFs/files you want, and it’ll automatically upload them all and preview them inside the app (except videos).
We upload several GBs worth of files in total every month. I think a coda doc would get real slow with that huge amount of files. Plus, I can’t upload multiple PDFs, Excels, Powerpoints or videos in a single column either
Right now, I’ve set up a coda doc for our HR, involving at least 10 tables with over 300 columns in total. Was planning to do the same for our content management system, but wanted to know if it was actually possible to do so, without slowing down the doc.
5 Likes
Any update on this? This is a much needed feature and with all the other clever tricks Coda can do, I am at a loss to understand why this is not supported. Embedding by using public URLs is not an option as I need to keep my google docs secure.
1 Like
There are several reasons why this isn’t just an easy solution and a couple have been mentioned in the asks on this thread. One is security and what permissions follow along with what’s posted in within a doc. It’s not an easy setup to figure out who can see what and how things change over all files within a doc.
Another issue is shear size of storage space that might be needed. With some docs that may have Gigs of attachments added, this can add up quickly and scaling servers is required on a different level to accommodate for doc storage vs. embedding links.
Neither security or scaling infrastructure are quick fixes.
That said, we are always looking at new solutions and this is one that is discussed. We’ve seen lots of use-cases where this would help out.
In summary, there isn’t a timeframe on when we will be expanding this but it is a known request with valid use-cases to support it.
2 Likes