Combining multiple Forms in Coda
How to integrate feedback
The idea for this blog came when I responded to a question in the community. It was about how to bring data together of 3 tables into one table. My response was to create a forth table that brings in the values from the separate tables via formula.
The contribution of Piet was to only use one table. The main advantage of the Piet proposition is that you have all your data in one single table. You need to create a lookup showing the events and per form one is selected. You cannot preselect the event for the user. However you can limit the mistakes by relating the date to the event.
First I show you how you create separate tables — one per event — and bring all the data into one table. Second I create one table and one form.
3 tables — 3 forms
When you have per event a table and a form and you want to have the outcomes aggregated, you set up an automation. A form generates a new row in the table is is a view of. Forms, cards, time lines etc are all views of the same table. The look is different, the underlying fundament is the same. You use an automation to bring all data you automatically in the table the form is based on, also in an other table. In our example this other table is table 05. Below how it goes. With three tables, you have 3 automations, all triggered by the same event: form filled out.
When a form is submitted in table 03 you add a row in table 05 and you set the date and the attendance. You do that by referencing step 01 result. This is the way Coda handles automations.
This you apply for the three tables and you have your solution. At the end of this blog a link to a doc showing this principle.
Date related complexities
Before sharing how to work with one form a few words about the weekday and week number logic. In this contribution you see how easily you get confused. The key problem I see is that one function can have two outcomes. Coda should clean up this approach of regional settings in your doc and replace it with a formulaic approach. I propose that you have the option to see alle weekday type of functions or only one.
- Weekday() — Sunday as first day of the week
- isoWeekday() — Monday as first day of the week
- friWeekday() — Friday as first day of the week
- satWeekday() — Saturday as first day of the week
Likewise for week number. It would bring back order in world of chaos. More than once I observed that a function no longer outputted what I thought it should until I realized the settings of the doc played a role. Weird and not professional.
One table — One form
The best way is to move forward is as Piet suggested. However many makers need to see the example before they can apply this rather simple logic. It starts with a table that contains the events we deal with, see below.
I added also a start & end date, something one can use to make the forms smarter. We dive into that after we covered the basics. You start with creating three forms based on the same table.
In your form you relate to the lookup. This is — as you can see — an easy to use solutio.
Smarter with dates
Since each event has a start & end date, we can create a warning and allow only dates that fit the event. We rework the event names and the order of the questions are we are all set.
Here we are with simple solutions to keep things together. When you want to see this in action, have a look at this template:
I hope this article was informative and helpful. Did it help you to solve a problem you unlike would have solved other ways? What about a donation?
My name is Christiaan, and I regularly blog about Coda. While this article is free, my professional services (including consultations) are not, but I’m always happy to chat and explore potential solutions. You can find my free contributions in the Coda Community and on X. The Coda Community is a fantastic resource for free insights, especially when you share a sample doc.
