Coda forms and form integration

Hey guys! I didn’t see this in the suggestions. It would be great, if we could use our coda table as a form. For example we have kind of crm, which records all our clients’ cases. Now we use a contact form on the website and need to manually copy/paste the data to Coda. It would be great, if we could do one of those:

  1. directly use coda form (I believe airtable has this option) or
  2. integrate other form with Coda and automatically receive the data in Coda

Thanks again to the amazing Coda team! I am reading the forum a lot and always find new and useful information. With every update the app gets better!



Some direct form integration would be amazing to help trigger processes

These might help you guys:

Thanks Dalmo, unfortunately TypeForm is too bulky for the form entry we need.

I just need a basic data form that pulls some logic from Coda such as dropdown etc, but also includes mandatory line items as well.

Customer facing - Typeform looks beautiful, it grates after a bit though

1 Like

Hey all,

We’re doing some research as we explore options for Coda Forms. If anyone in this thread could help provide more context on your needs and has 30 minutes to spare in the next couple of weeks then DM me :slight_smile:


Hey @Glenn_Jaume
I’m short in time but in interested by a Coda Form.
The easy way would be a Google Form pack.
I also saw an Airtable form that was quite pretty.

The main thing to have in mind for form is that there shouldn’t be a dialog for connection to the service. People should be able to fill the form directly without any friction.
Also the interface have to be very minimalistic and easy to use.

If you’d like we could have a chat via Email, but I’m sorry I will not be able to give a lot of time.



I’m not typically engaged in forms-building for my clients, but the other day I was asked if I could build a dynamic (Google) form by simply reading a schema from Coda. This approach allows G-Suite businesses to instantiate a new form by simply setting up a Google spreadsheet with some basic information and running a script from a pull-down menu.

In my assessment of this client’s project, the design makes it possible to automate just about everything - it reads the Coda target table, builds the web service, deploys it, and then provides the form URL for capturing data.

Implementing this approach as a Pack would be pretty straightforward.


would love to have a form on our website for job candidates and have their info in coda.
we are a design agency, so the most important field in the job form is a portfolio upload.
These can be large files…
saving that file somewhere on our google drive and then a link in coda to that file would be ideal. (because all files in a coda doc would make the doc to big)

1 Like

I really want to see forms be part of Coda, and not just a Pack. Close-coupling of data with the form (filtering values based on other columns, editing existing rows) requires the form to have advanced knowledge of the table(s), and I don’t think it can be done easily in a third-party service.

With that in mind, I think Layouts would be the best way to go. The current Layouts work like somewhat like forms already. However they have been given much less attention than the rest of the UI. Updating Layouts with the following features would be killer:

  • Colors (either shared Conditional Formats from the table itself or even better, independent Conditional Formats for Layouts)
  • Better control of font/sizing
  • Fix some of the UI inconsistency (several fields don’t respect the Alignment setting very well, for example; vertical-alignment isn’t great at all)
  • Grid-positioning of controls (current method is very limited–i.e. no empty columns without exploiting a glitch)

Just using a Layout (with the above enhancements, hopefully) separately from Coda (embedded, etc.) would make a great forms interface, and would keep a lot of the magic of the existing formulas.


@Ian_Nicholson a bit off topic but I must agree with you that Layouts still needs more polishing and more features.


@tomavatars perhaps, but Layouts feel like an unfinished Forms feature already. I’m just worried that Coda may stop at third party Forms integration when they are almost there with the Layouts feature.

Hey @Glenn_Jaume, I found this thread when looking around for any previous mention of Typeform or Google Survey Pack suggestions. So my vote would be for not just a generic form, but an integration to one of these survey builders. If you could put up a survey, then link it to Coda to create action points directly, I think that would be super powerful. Right now when my team runs a survey, which we do rarely, we are not really able to seamlessly integrate the survey with any action items. We have to create completely separate tasks, notes, etc. very disconnected from the survey itself. If you could connect the survey to Coda, and possibly take certain results and associate rows, that would be essentially tasks or mini-projects inside Coda, referring back to the survey as these rows/projects are worked on, I think that would be a hugely beneficial feature facilitated by packs.

Hope that makes sense, and as always eager to see what you guys come up with!


Ideally we would have both a Coda forms (perhaps an amped up version of the current Layouts) AND Coda packs (Typeform, Google forms, etc) since they have different advantages and different use cases.

However, I would argue that the packs are the higher priority. @Glenn_Jaume

Because the primary advantage of having a form that is like Layouts is that it will (hopefully when implemented) be able to pull data from your doc for things like select-list and formulae. However, this probably only useful when what you really want is for users to add data directly to a growing document, and maybe even interact with it. And if that’s the case, you can share the doc with them, or put a nice-looking “Submit Response” button on a section of your doc and embed it on your website.

Typeform and other form-building services, on the other hand, are likely far more powerful and nice-looking than Coda forms are likely to be in the near future, so might as well piggy-back on their investment, and just pull the data into Coda via Packs which gives you excellent control over then mapping responses to rows and such.

Hey Glenn, not sure if you’re still looking for input from people, but I could spare 30min this month. :slight_smile:

Hey Ryan,

We’re still looking into all our options, we’ll have something to announce soon (It’s not forms) but it’s moving in that direction :slight_smile: I’ll let everyone in the thread know when we need more help with forms specifically.

Thanks everyone for your feedback so far!


One of the main issues with forms is the distinct authentication realm that they live in. Coda has come a long way on permissions from a year ago, but still has a long way to go on handling authentication and permissions on docs and sections and elements and so on before it can serve as a public-private tool for business without external integration. I’m not knocking anything, developing collaborative applications and deciding what the rules are and how to enforce them with so much going on behind the scenes has to be tough.

Still, the concern I have on forms is that they would act like any other business form that is of any use outside of large corporations, and that means the first rule is that the form has to be shareable, publicly, and can have a distinct set of authentication rules from the data source it’s tied to. Usually, this is handled by instituting a hierarchy of authentication that has at least these three levels:

  • Private (Internal Coda Auth)
  • Public-Private (Passworded)
  • Public

If it isn’t shareable with non-Coda authentication, then it’s not going to be useful for public facing business, only those using it for internal functions.

Just wanted to toss that in since most of the discussion was only about packs vs. integrated and I thought it was worth mentioning.

Looking forward to whatever you’re going to introduce next @Glenn_Jaume :slight_smile:

Any progress on this Glenn?

Really surprised Coda does have its own forms. It seems to be a function that’s so foundational.

Airtable has their own forms. Smartsheets have their own forms. Google Sheets have their own forms.

Could you elaborate on what you mentioned a couple of months ago you would soon announce soon that was not forms but moving in that direction?


Also curious what’s moving in that direction. Perhaps they meant publishing docs that can have actions you perform (like that pack voter doc).

Meanwhile, a half-baked solution with two docs and cross-doc actions:

No particular update (we’re not ready to announce anything on forms)

The update I was referring to was Coda publishing was has allowed for some of the forms use cases as Paul mentions. More the voting side of it than an actual form.

We’re working hard on many features as always, just a case of priority :slight_smile: hopefully have more to share on this in the future.

1 Like

Thanks Glenn.

No doubt prioritization would be an interesting task on your end.

Please include our vote for the forms.