Add recurring meetings to your calendar in Coda
Using buttons and tables
Coda, with its table logic, offers a unique way to manage recurring meetings. In a table each row represents a meeting, containing all the essential details: date, start time, end time, subject, meeting content and more.
In this post, we’ll explore how to automate the creation of recurring meetings in your calendar of choice (Google Calendar, Outlook, etc.) directly from a Coda table. Using an interactive button, you’ll be able to:
- Define complex recurrence patterns: “Every Monday at 9am”, “Every second Monday of the month”, and so on.
- Automatically capture user information: The button will identify the user who’s active in the Coda doc and use that information to create the meeting in the calendar of choice.
The main advantage of using Coda in this scenario is not that you cannot create recurrent items in your calendar directly (that goes really very well!), but that you can handle your meeting notes at one place, while the time based logic lives in a dedicated application: the calendar. In this scenario Coda’s main role is to provide you an overview of your linked data and keep it all together.
The set up
I stumbled upon an interesting quirk when working with date-time values and recurrence patterns. The initial idea of setting a start date-time and calculating subsequent occurrences based on daily, weekly, or monthly intervals is sound. However, the issue arises when using the function relativeDate() for monthly calculations. While adding days preserves the original time component of the date-time value, using monthly deltas resets it to midnight.
The key takeaway here is that when dealing with recurrence patterns involving date-time values, adding months behaves differently than adding days. To maintain the original time component, you’ll need to split the date-time value into separate date and time components. This allows you to perform calculations on the date while preserving the time, which can then be recombined for the final output.
The working logic — step 01
To keep our date-time calculations accurate, we need to handle the date and time separately. As you can see in the screenshot, I’m taking the year, month, and day from our start date and combining them with the hour and minute from our start time. This lets us rebuild the full date-time, ensuring we don’t lose any information during our calculations.
We adapted the original code to handle recurring dates and times. We kept the logic for days but changed the logic for relative dates (months). Since the “month” property doesn’t consider the time, we had to merge it with the date. The result is satisfactory for a first step. To manage events over a year, further adjustments will be needed.
Step 02 — getting all the values in the period ahead
To establish a robust system for recurring events, we first need to determine the end date of the recurrence. This is achieved by taking the user’s chosen duration (e.g., 3 months, 1 year) and adding it to the start date. We accomplish this with the relativeDate function, which cleverly utilizes numerical values assigned to each frequency (daily = 1, monthly = 12, etc.). This approach provides flexibility and scalability for handling various recurrence patterns. With the start and end dates established, we can then move on to calculating the intervals for the recurring events.
Step 03 — calculating the monthly intervals
To generate a schedule for recurring meetings, we need to determine the dates on which the meeting will occur within a given timeframe. If your first meeting is on December 8th, and it occurs monthly, then your next meeting would typically be on January 8th.
To calculate these dates, we need to figure out the intervals between each meeting. For weekly meetings, this is easy — we just add 7 days for each new date. Monthly meetings are a bit trickier because months have different lengths. For now, we’ll keep things simple and assume that monthly meetings always fall on the same day of the month, regardless of the weekday.
Let’s start by tackling the challenge of monthly intervals. Since months can have 30 or 31 days (and sometimes even 28 or 29!), we’ll need a way to account for these variations.
To determine the dates for recurring meetings, we first analyze the frequency of recurrence (e.g., monthly, quarterly) and the extended period over which the meeting will occur (e.g., 3 months, 2 years). We use a simple division to calculate the number of intervals within the extended period. For instance, a monthly meeting occurring over 3 months would have 3 intervals (3 months / 1 month).
Next, we utilize the sequence function to generate a list of numbers representing these intervals. This list helps us track the progression of the recurrence.
To generate the recurring dates, we utilize the relativeDate function, which allows us to shift dates forward or backward. We cleverly combine this with a loop that iterates through intervals, represented by CurrentValue. By multiplying CurrentValue with the repeat frequency (e.g., 1 for monthly, 12 for yearly), we dynamically add the correct number of months to the startDate, effectively generating the dates for each recurrence.
This approach may seem complex at first glance, but it’s actually quite straightforward. It elegantly handles various repeat frequencies by simply adjusting the multiplier within the relativeDate() function.
In the final step, we combine the calculated dates with the original start time of the meeting. This ensures that each recurring meeting maintains its designated time. To achieve this, we iterate through the list of dates and append the start time to each. We then convert these combined values into a proper date-time format, finalizing the schedule for all future meetings within the extended period.
Quotient(thisRow.[extended period].nbrMonths,thisRow.repeats.nbr ).WithName(intervals,
Sequence(1,intervals).ForEach(
thisRow.startDate.RelativeDate(CurrentValue * thisRow.repeats.nbr) + thisRow.startTime)).ForEach(CurrentValue.ToDateTime())Step 04 — calculating the daily occurrences
For recurrences based on days (daily, weekly, etc.), we can use a simpler approach by leveraging the Sequence() function. This function allows us to generate a series of dates with a specific interval.
To make this work for different repeat frequencies, we use a switchIf() condition. This condition checks if we're dealing with day-based recurrences. If we are, it applies the appropriate interval within the Sequence() function. For instance, a daily recurrence would have an interval of 1, while a bi-weekly recurrence would have an interval of 14.
This approach provides a more streamlined way to handle day-based recurrences compared to our previous method for month-based recurrences. We essentially have two distinct approaches: one for months using relativeDate() and one for days using Sequence() with an interval.
While setting up the button itself is straightforward, the true challenge lies in the logic we’ve developed to accurately calculate the recurring dates, taking into account different intervals and time units. This logic forms the foundation for generating the date-time ranges displayed in the button.
In what follows, l explore how to seamlessly add these individual meeting instances to the user’s calendar using the Coda Calendar Pack.
Adding the meetings to your calendar
To integrate our recurring meeting functionality with Google Calendar, we utilize Coda’s Google Calendar pack. This pack allows users to interact with your calendar directly through an action button or an automation. We go with buttons in this scenario that can add new events, update existing ones, or delete events as needed.
Importantly, we’ve configured the pack to operate in ‘private’ mode. This means each user’s actions affect only their individual calendar.
The Google Calendar pack itself is user-friendly, even for those with limited experience with integrations. Within the pack settings, you simply select the desired action (add, update, or delete) and configure the necessary details, such as start time, end time, description, and title.
One interesting aspect is handling the scenario where a meeting might already exist. We’ve implemented a trigger that checks for existing events. If an event is found, the button updates it; otherwise, it creates a new event. This ensures smooth and consistent behavior.
In the following sections, we’ll delve deeper into how we set up this calendar integration to handle adding, updating, and deleting events effectively. In this post I limit myself to some observations, check out this community post for more details.
When setting up the Google Calendar integration, it’s best to start by utilizing the predefined fields provided by the pack since they often have their own logic and structure.
For example, to specify the start date for an event, you’ll need to select the ‘f’ option within the pack settings instead of using the typical Coda date options like ‘Today’ or ‘Tomorrow’. This can be slightly confusing at first, but in general, following the pack’s guidance ensures a smooth setup.
This pack approach highlights the transition between Coda’s low-code environment and the no-code nature of packs. While packs simplify many tasks, they might require a slight shift in how you approach configuration. I used for example the + add more button add attendees and other variables.
Once you’ve configured the pack using the provided options, you can access the underlying code snippet by clicking the ‘f’ symbol in the top right corner (as you can see below). This code snippet can then be used for further integration or customization.
To enable event updates, we replicated the setup process and created a second button dedicated to this function. This involved following the same steps as before, but this time configuring the pack for updating existing events instead of creating new ones. The outcome of both buttons I glued together in the final button, see below.
While this exploration of recurring events and calendar integration has been extensive, it’s important to remember that such solutions are often context-dependent. What works perfectly in one scenario might require adjustments in another. The true value lies in refining the solution to meet the specific demands of the production environment.
I hope this overview has provided valuable insights into the logic and mechanisms of Coda’s formula language and the nuances of working with packs. While I appreciate the capabilities that packs offer, there’s room for improvement in terms of user experience and ease of use.
I believe that with some refinement, Coda can make packs more accessible and intuitive, empowering a wider range of users to harness their capabilities. I hope Coda employees are reading along with me here.
Thank you for joining me on this exploration. I welcome your comments, questions, and feedback. 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.
