Master calendar

I need to represent events (title, start, end) from several different tables:

  • Academic dates (semester start, end, holiday…)
  • Dates from particular classes (exam, party…)
  • Student trips (including hourly itinerary dates)
  • Instances of new-student onboarding (admission date, visa date, arrival date…)
  • Task/planner dates (current start & end, drop-dead)
  • Various unique projects, committees…

A single table with lookups won’t work because the records are different animals–I’m interested only in the events from those other tables.

AirTable (via lookups and a tweak to their calendar) and Google Calendar (via subscription) represent events from multiple sources without having to use third parties.

1 Like


Welcome to Coda! I see that you just joined.

What you have described in your post is non-trivial. Fortunately Coda is a non-trivial solution.

There are two main ways to go about this.

One is to get an experienced Coda person to do the development for you.

The other is to do it yourself, but you will need to get to know Coda first, and what it can do. Coda is very easy to use, which unfortunately makes it also very easy to start down the wrong track with an example like what you described.

You will find that all these no-code tools are very similar, but they are different in subtle ways. These subtleties will hurt you twice. Once while you try to shoehorn Coda into the tools you already know, and again when you mis out on all the functionality that Coda has to offer.

A good starting point is the following:

And their youtube channel:

Paul Danyliuk provides helpful information here

Getting closer to your doc:
There are multiple ways in which it can be approached. You can pull in existing templates and docs to handle, say, your onboarding or task/ planner dates. There are several very good ones in the gallery. Then add the additional requirements around that.

You could do everything from scratch. And don’t assume that different “animals” need to be in different tables. (Coda is not a traditional relational database, so 3rd normal form does not apply.)

In the third instance, you can use the Calendar pack to send calendar events from the various sub-docs you develop to Google Calendar, and keep using the Google Calendar functionality.

Whichever approach you take though, I would strongly recommend that you take a hundred to two hundred hours to familiarise your self with basic coda, its table structures, formulas and packs, and build a prototype or three before you embark on a large project like the above.

Happy building
Rambling Pete

The first approach seems promising. Might you (or someone here) be able to give an example of what “pulling in existing templates and docs” might look like? For example, how might I represent semester dates (think final exam week) and course dates (think final exam date for each course) within a single table or view? I can put them in columns side by side—but then I just need them to overlap 100% :slight_smile:

As for the second approach, higher numbers of records and fields in a table seem to noticeably delay, and aproach three doesn’t allow manipulating a multi-source calendar with Codas endless tools (say, to see if a teacher’s final exam is scheduled during final exam week), and requires syncing and attending to a third party.

I appreciate your advice, and look forward to learning more!

HI Nicholas,

Welcome to Coda!

If, from your doc, you click on Insert, and then Template, You will get the screen below

This allows you to search through the templates, you simply drag the template you like into your doc.

To copy a doc: If you go to the Gallery as shown below, you can make a copy of any doc or pack in the Gallery,

As for your more solution specific questions - Those are more consulting topics - it is difficult to propose something without a more complete understanding of the exact requirement. Any design will be compromises between different options. For example table sizes. Yes, Coda is not designed to be a database handling tens of thousands of rows. So after some experience, one will know when and how to split tables. (And docs).
Depending on the kind of data

  • you could split on time based criteria - monthly annual, etc
  • Or you could archive older records no longer needed quickly.
  • Etc


This is the same problem posed in the post here: Polymorphism would be nice: a way to join tables with common columns under a parent or generalized table - #2 by loucadufault

You can see the first comment I made specifically with 4 different approaches to this problem.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.