Google Calendar

On the Google side sits a user's calendar list: a primary calendar, secondary calendars they own, calendars shared with them, and the free/busy information Google exposes for each. Events carry a start and end, a time zone, attendees with response status, a location or conferencing link, a recurrence rule and a visibility setting. On the AppBO side sits a booking calendar, who can be booked, in what slot length, within what working hours, with what buffers, notice period and daily cap, attached to a user and to the workflows that confirm, remind and follow up.

You wire them together because a booking calendar is only as good as its view of reality. A slot offered while the owner is already committed elsewhere is worse than no slot at all. Connected in both directions, the platform reads Google to know when a person is unavailable, and writes back so anything booked through the platform appears where that person actually looks. Their calendar becomes the single place they manage the day; the platform becomes the single place leads book it.

The connection is per user, not per sub-account, and that detail shapes everything else. Each team member authorizes their own Google account and the platform holds a token for that user. Straightforward for a solo operator, a matter of discipline for a team. The one person who never finished authorizing becomes the one person whose double bookings nobody can explain.

1. Decide which Google account each team member will connect. A personal account and a Workspace account can both be connected, but availability is only as reliable as the account that holds the real commitments.
2. Confirm the user's profile in AppBO carries the right email and, critically, the right time zone. A mismatched time zone between the user profile, the booking calendar and the Google calendar is the most common source of slots appearing at the wrong hour.
3. Open the integrations area of the sub-account, or the calendar settings on the user's own profile, and start the Google connection. The exact menu label differs between platform versions. Look for the calendar or integrations panel and verify against current platform documentation if the wording differs.
4. Complete Google's OAuth consent screen signed in as that user. Review the permissions requested on the screen itself and grant them; do not assume a particular scope string, as these change and the consent screen is the authoritative list.
5. If the account is a Workspace account under admin control, check whether third-party app access is restricted. An administrator may need to allow the application before the consent screen will complete for anyone in the domain.
6. Once connected, choose the calendars to read for conflicts. Select every calendar that holds real commitments, including shared team calendars and any personal calendar the person actually uses.
7. Choose the single calendar the platform writes to. Only one target calendar should receive platform-created bookings; writing to several creates duplicates that then read back as conflicts.
8. Set the sync direction deliberately. Two-way means read conflicts and write bookings. One-way read is appropriate for a person whose bookings must stay in another system.
9. Configure the booking calendar itself: slot duration, working hours per weekday, buffer before and after, minimum notice, maximum days ahead, and the daily or weekly cap.
10. For a team calendar, set the distribution rule (round robin, priority weighting or equal distribution) and confirm every assigned user has completed their own Google authorization. An unauthorised user in the rotation will be offered without conflict checking.
11. Decide what the written event contains: title pattern, description, whether the contact is added as a Google attendee, and whether a conferencing link is generated.
12. Verify the read direction. Create a test event directly in Google during a slot the booking page currently offers, wait for sync, reload the booking page and confirm the slot has disappeared.
13. Verify the write direction. Book a test appointment through the booking page and confirm it appears on the chosen Google calendar with the correct time, time zone and attendees.
14. Verify the edit and cancel paths. Reschedule the test booking in the platform and confirm Google follows; cancel it in Google and confirm the platform reflects the cancellation.
15. Confirm the notification workflows fired for the test booking (confirmation, reminder and any internal alert) then delete the test data.
16. Record which user connected which account and on what date, so an expired token later has an owner rather than becoming a mystery.

Platform to Google

• Event creation for each appointment booked through a connected calendar, written to the single chosen target calendar.
• Start and end time, derived from the slot and the booking calendar's time zone.
• Event title built from the calendar's title pattern, usually combining the service name and the contact name.
• Event description, which typically carries the contact's phone and email, the answers to any booking-form questions, and a link back to the contact record.
• Attendees, where the calendar is configured to add the contact as a Google guest, which is what lets Google send its own invitation.
• Conferencing link, where the calendar is set to generate one.
• Updates and deletions when an appointment is rescheduled or canceled in the platform.

Google to the platform

• Busy intervals from every calendar selected for conflict checking, which remove slots from the booking page.
• Changes to platform-created events: a start time moved in Google, or the event deleted, flowing back as a reschedule or cancellation.
• Attendee response status on platform-created events, where the platform surfaces it.
• The calendar list itself, so you can choose which calendars to read and write.

What does not move

• Historical events from before the connection. Nothing backfills; only forward-looking busy time is considered.
• Events created directly in Google do not become appointments on a contact record. They block time; they do not create CRM data.
• Google Tasks, Keep notes and reminders. Only calendar events are in scope.
• Guest lists of third-party events. Conflict checking reads busy time, not who else is in the meeting.
• Google's own notification settings. Google reminders and platform reminders are separate systems and will both fire unless you turn one off.
• Recurring-event exceptions in full fidelity. Treat complex recurrence as read-only and verify behavior before relying on it.

Scenario: a lead books a consultation from a round-robin team calendar, the assigned rep then has a conflict, and the booking is rescheduled.

1. A lead submits a form and a workflow sends them the booking link for the two-person consultation calendar.
2. The booking page loads and the platform requests busy time from both reps' connected Google calendars for the visible date range.
3. Rep A has a personal appointment on Thursday morning on a secondary calendar that was included in conflict checking. Those slots are removed from the offered availability for Rep A.
4. Rep B is free Thursday morning, so the slot remains offered and the round-robin rule assigns it to Rep B.
5. The lead picks Thursday at ten and submits the booking form, answering one qualifying question.
6. The platform creates the appointment against the contact record, assigns it to Rep B, and writes an event to Rep B's chosen Google calendar with the contact's name in the title, the phone number and the form answer in the description, and the contact added as a guest.
7. Google sends its invitation to the lead, who accepts. The response status appears on the event.
8. An AppBO workflow triggered by appointment booked sends a branded confirmation email and schedules a reminder for the evening before and an SMS two hours ahead.
9. On Wednesday, Rep B accepts a client meeting that overlaps and moves the consultation event forward an hour directly in Google.
10. The change syncs back. The platform updates the appointment time, and the reminder workflow recalculates so the reminders fire relative to the new time rather than the original.
11. The lead receives an updated confirmation. The Thursday ten o'clock slot becomes available again on the booking page, and the eleven o'clock slot is now blocked.
12. Thursday arrives, the meeting happens, and Rep B marks the appointment outcome in the platform. A follow-up workflow fires on that status change and the opportunity advances.

Rate limiting

Google applies per-project and per-user quotas to its Calendar API, and a busy sub-account with many connected users and heavily trafficked booking pages shares that budget. Symptoms are stale availability rather than an error message: the booking page shows slots that were filled an hour ago. Google publishes current quota figures in its API documentation and surfaces usage in the Cloud console: check there rather than assuming a number.

Retries and idempotency

Write operations are retried on transient failure, and a retry that succeeds after a timeout can leave two events for one booking. If you drive event creation yourself through the API rather than through the native connection, supply your own event identifier so a repeat is an update rather than an insert. On the platform side, treat appointment-booked as the idempotency anchor: a workflow that can run twice on the same appointment will send two confirmations, so guard it with a tag or a field check.

Field-mapping traps

Time zone is the trap that matters. The user profile, the booking calendar, the Google calendar and the contact can each carry a different zone, and the booking page renders in the visitor's. Verify by booking across a zone boundary rather than by reasoning about it. Event titles and descriptions built from merge fields will render literal placeholder text when the field is empty, so give every merge field a fallback. Adding the contact as a Google guest means Google emails them directly, which can arrive before or instead of your branded confirmation: decide which system owns that message.

Duplicate creation

Duplicates come from three places: a user who connects two Google accounts that share events; a target calendar that is also selected for conflict reading, so the platform's own event blocks the slot it just filled; and a second platform calendar writing to the same Google calendar. Keep one write target per user and exclude nothing from conflict reading except that write target, if the platform allows it.

Sandbox versus live

There is no sandbox calendar. Test against a throwaway Google calendar on a real account, and clean up test events afterwards, because leftover test blocks silently remove real availability.

Authentication expiry

Tokens expire. A password change, a revoked app grant in the Google account's security settings, an administrator tightening third-party access, or long inactivity can all break the connection, and the failure is usually silent. The booking page keeps working and simply stops checking conflicts. Build a habit of checking the connection status for every user on a schedule, and re-authorize rather than troubleshooting elsewhere when availability looks wrong.

What commonly breaks

• A new team member added to a round-robin calendar without connecting their own Google account, so they are offered every slot in their working hours.
• Someone marking a block as free rather than busy in Google, which makes it invisible to conflict checking.
• All-day and multi-day events behaving differently from timed ones; verify how your configuration treats them.
• Recurring events whose individual exceptions do not propagate as expected.
• Buffers set on the booking calendar but not accounted for by the person's other bookings, producing back-to-back meetings with no travel time.
• Google's own invitation emails confusing contacts who also receive a platform confirmation with a different reschedule link.
• A shared calendar whose permissions are read-only, which silently blocks the write direction.