Create Google Calendar bookings with Make: event IDs, changes and cancellations

Choose the booking source of truth

Use a booking table containing an immutable booking ID, state, start time, end time and timezone. Calendar is the display destination. Creating an event does not reserve capacity atomically or prevent double selling; confirm availability in the booking system first if that guarantee matters. Use a dedicated practice calendar with no attendees for the initial checks.

Validate timestamps before creating events

A sample booking is BOOK-301 from 2026-11-02T10:00:00+09:00 to 11:00:00+09:00. Preserve an explicit offset. For local timestamps without one, identify the source timezone before parsing. Reject missing or invalid times and an end before the start. Substituting the current time for an invalid value produces a plausible event that is still wrong.

Fix the destination calendar

Authorize the Google Calendar connection and select the practice calendar explicitly. Map the event summary, start and end, including the booking identifier in the summary for reconciliation. Review attendee and notification settings independently. Do not add real customer addresses while checking configuration; use a controlled address only when you intentionally test invitation behavior.

Save the returned event identifier

Store the returned event ID and calendar ID against the booking ID. Updates should use those identifiers instead of selecting the first title search result. If event creation succeeds but saving its ID fails, inspect the calendar before repeating creation. An absent saved ID does not prove that the event was never created, and unconditional retries can create duplicate appointments.

Process rescheduling and cancellation separately

Update an existing event using its saved ID when a confirmed booking changes. For cancellation, check booking state, cancel the intended event and retain the original identifiers and cancellation time. Decide how to handle an event manually deleted from Calendar. This exercise covers single appointments; recurring events require additional rules for series and individual occurrences.

Test repeats and timezone boundaries

Repeat the same booking, use a booking crossing midnight, change its time and cancel it. Expect updates to the same event rather than extra copies. Reconcile source timestamps with both the calendar timezone and displayed time. Before notifying customers, test the update and cancellation notification settings using your own controlled recipient, checking actual messages rather than assuming how they behave.

Define ownership before attempting two-way sync

Sending calendar edits back to the booking table introduces conflicts and stale updates. Decide which system wins and how update versions are compared before building that direction. A one-way table-to-calendar flow limits the first rollout. Estimate lookups, creation, updates, identifier storage and retries, not just the number of appointments. These steps describe a proposed testable setup, not a completed account execution.

• Make date and timezone settings: convert to Japan time and compare deadlines
• Prevent duplicate writes in Make with stable keys and recovery states
• Send spreadsheet deadline reminders with Make without daily duplicates